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ABSTRACT 


The  Marine  Air  Command  and  Control  System  execution  of  Direct  Air  Support 
is  based  on  the  concept  of  centralized  command  and  decentralized  control.  It  is 
completed  manually  using  standardized  procedures  and  controls  to  ensure  responsiveness 
in  highly  dynamic  situations.  This  thesis  investigates  the  issues  in  developing  and 
implementing  an  automated  database  application  for  receiving,  processing,  disseminating, 
and  recording  information  as  it  pertains  to  the  Air  Tasking  Order  within  the  Direct  Air 
Support  Center.  A  relational  database  design  is  proposed  using  Entity-Relationship 
modeling.  A  simple  prototype  of  the  system  is  implemented  in  dBASE  IV  to  demonstrate 
proof  of  concept.  The  major  benefit  of  the  database  approach  is  that  databases  are 
dynamic  and  can  evolve  with  changing  needs. 
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I.  INTRODUCTION 


A.  BACKGROUND 

Information  has  always  been  the  most  important  resource  in  command  and  control 
decisions.  Unfortunately,  commimication  has  been  viewed  as  a  distant  relative  of  the 
military  profession.  It  is  only  in  the  last  couple  of  decades  that  information  systems  to 
support  the  command,  control  and  communication  processes  have  been  recognized  in  their 
own  right  by  the  military.  Technological  advances  in  the  development  of  digital 
techniques  for  the  representation  and  processing  of  information,  and  microelectronics  have 
led  to  the  fulfillment  of  long  existing  information  requirements.  Automated 
conununications  and  information  systems  have  enabled  decision  makers  to  cope 
effectively  with  the  complexity  of  command  and  control  on  the  battlefield. 

The  Marine  Air  Command  and  Control  System  (MACCS)  execution  of  Direct  Air 
Support  is  based  on  the  concept  of  centralized  command  and  decentralized  control.  It  is 
completed  manually  using  standardized  procedures  and  controls  to  ensure  responsiveness 
in  a  highly  dynamic  situation.  Based  on  the  information  contained  in  the  Draft 
Operational  Requirements  Document  (ORD)  for  the  Direct  Air  Support  Central,  Marine 
Corps  Combat  Development  Command  identified  operational  deficiencies  in  the  data 
processing  capabilities  of  the  Direct  Air  Support  Center  (DASC).  The  DASC  requires  an 
automated  message  and  information  handling  capability  to  exchange,  store,  display,  and 
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manipulate  digital  infonnation  using  established  Marine  Tactical  Systems  and  Message 
Text  Format  (MTS/MTF)  standards. 

This  thesis  investigates  the  issues  in  developing  and  implementing  a  database 
processing  system  for  receiving,  processing,  disseminating,  and  recording  information 
required  by  the  DASC  as  it  pertains  to  the  Air  Tasking  Order  (ATO).  Background  of  the 
MACCS,  DASC  functions,  the  ATO  cycle,  and  lessons  learned  from  Operation  Desert 
Storm  are  discussed.  Application  of  an  integrated  Database  Management  System  (DBMS) 
within  the  DASC  will  be  explored  addressing  system  and  joint  inter-operability 
requirements/problems.  Man-machine  interface  will  be  stressed  in  the  DBMS.  The 
potential  use  of  this  system  wiU  be  researched  to  improve  the  efficiency  and  effectiveness 
of  information  flow  and  decision  making  within  the  DASC,  the  MACCS,  and  the  Fire 
Support  Coordination  Center  (FSCC). 

B.  SCOPE 

The  focus  of  this  thesis  is  a  system  requirements  review  of  an  integrated  DBMS  for 
the  receiving,  processing,  disseminating,  and  recording  of  the  ATO  in  the  DASC. 
Research  is  specifically  intended  to  model  a  system  that  uses  available  data  in 
standardized  format  to  build  a  database,  query  the  database,  and  then  utilize  the 
information  to:  (1)  provide  information  to  decision  makers,  (2)  disseminate  information 
to  those  who  require  it,  (3)  add  and  subtract  information  within  the  database.  Research 
will  cover  database  architecture  in  an  integrated  DBMS  to  include  consideration  in  man- 
machine  interface. 
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C.  THESIS  OBJECTIVES 


The  primary  objective  of  the  thesis  is  to  identify  the  system  and  information 
requirements  for  a  database  processing  application  that  automates  the  ATO  functions 
within  the  DASC.  This  will  entail  the  following  steps; 

1 .  Determine  the  feasibility  of  automating  the  ATO  functions  within  the  DASC. 

2.  Demonstrate  the  potential  to  improve  information  flow  and  decision  making  within 
the  DASC. 

3.  Highlight  problem  areas  in  developing  and  implementing  a  DBMS  for  uf  in  the 
DASC. 

4.  Translate  the  user  defined  data  requirements  into  a  conceptual  model,  and  design 
and  build  a  database  using  that  model. 

D.  RESEARCH  QUESTIONS 

There  are  several  approaches  to  implement  a  database  processing  application.  The 
primary  research  question  is  to  determine  the  information  requirements  for  a  database 
application  and  generate  a  database  design  that  fulfills  the  determined  requirements.  In 
support  of  the  primary  question,  the  thesis  will  identify  the  system  requirements  of  an 
automated  database  and  the  design  issues  to  be  addressed  in  modeling  the  proposed 
system. 

E.  LITERATURE  REVIEW  AND  METHODOLOGY 

Background  knowledge  on  the  subject  area  was  obtained  through  research  into 
technical  reports,  academic  publications,  and  a  course  on  relational  databases.  The 
doctrinal  and  operational  knowledge  was  gained  from  doctrinal  publications,  technical 
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reports,  DASC  project  documentation,  and  interviews  with  Marines  in  the  air  support 
control  community. 

The  methodology  used  in  this  thesis  generally  follows  the  application  development 
process  outlined  by  Kroenke  and  Dolan  (1988,  p.  75-82)  which  consists  of  five  phases: 

1.  The  definition  phase  attempts  to  define  the  scope  of  the  project. 

2.  The  requirements  phase  determines  as  specifically  as  possible  what  the  new 
system  must  do. 

3.  The  evaluation  phase  studies  alternative  solutions  to  the  requirements. 

4.  The  design  phase  involves  creating  the  logical  stmcture  of  the  database. 

5.  The  implementation  phase  constmcts  the  system  according  to  the  design. 

The  scope  of  this  thesis,  as  defined  earlier,  will  look  at  the  user  requirements  of  a 
database  processing  system  and  model  a  database  based  on  those  requirements.  The 
thesis  will  emphasize  the  design  phase  of  the  database  based  upon  user  defined 
requirements.  Alternative  database  models  will  be  addressed,  and  implementation  of  the 
design  will  be  demonstrated  on  a  sp)ecific  microcomputer  DBMS. 

F.  SUMMARY  OF  HNDINGS 

The  intent  of  relational  database  design  is  to  increase  the  accessibility  of  database 
information  to  all  users,  minimize  redundancy,  and  allow  for  implementation  of  future 
applications  to  the  DBMS.  DBMS  capabilities  include  mechanisms  for  displaying  data 
through  report  generators  and  responding  to  "ad  hoc"  database  queries.  The  relational 
model  allows  data  independence,  meaning  that  applications  maintain  more  flexibility  for 
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changes  in  the  future  than  traditional  file  processing  approaches.  The  database  design 
developed  by  the  entity-relationship  approach  is  independent  of  and  not  restricted  by  the 
capabilities  of  any  specific  database  system.  It  can  be  implemented  in  any  relational 
DBMS  environment.  These  concepts  are  imjjortant  in  the  rapidly  changing  command  and 
control  environment.  As  users  see  how  automation  benefit  decision  making,  their  "need" 
for  additional  data  and  information  processing  will  grow. 


G.  ORGANIZATION  OF  THE  STUDY 

The  remainder  of  the  thesis  is  organized  as  follows: 

•  Chapter  11  provides  the  background  to  the  MACCS  to  include  the  DASC  ftmctions 
and  the  ATO  process.  It  lays  the  groundwork  for  demonstrating  how  a  DBMS 
could  improve  the  efficiency  and  effectiveness  of  decision  making  and  information 
flow  within  the  DASC. 

•  Chapter  HI  explores  the  technology,  man-machine  interface,  and  system 
requirements  of  an  automated  information  system,  and  identifies  the  information 
flow  requirements  within  the  DASC. 

•  Chapter  IV  explores  database  processing  concepts  to  include  design,  tools,  and 
techniques. 

•  Chapter  V  presents  a  database  design  and  implementation  for  the  DASC  application. 

•  Chapter  VI  summarizes  the  benefits  of  a  database  processing  reproach  for  the 
DASC  application. 
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11.  MARINE  AIR  COMMAND  AND  CONTROL  OPERATIONS 

A.  GENERAL 

This  chapter  presents  the  fundamentals  of  control  of  aircraft  and  missiles,  the 
MACCS,  the  DASC,  the  ATO  cycle,  and  lessons  learned  from  Operation  Desert 
StoniVShield.  The  objective  is  to  document  the  existing  MACCS  operational  environment 
and  eventually  to  identify  the  information  flow  requirements  of  the  DASC  with  respect 
to  the  ATO.  These  requirements  will  be  specified  in  Chapter  III  and  serve  as  the  basis 
for  constmcting  a  database  application  based  on  the  model  discussed  in  Chapter  IV. 

B.  CONTROL  OF  AIRCRAFT  AND  MISSILES 

The  capability  to  conduct  successful  tactical  air  operations  is  essential  to  the 
execution  of  military  operations.  The  Marine  Corps  has  organized  an  aviation  combat 
arms  capable  of  meeting  the  requirements  of  a  flexible,  responsive  aviation  combat 
element  specifically  tailored  to  meet  the  anticipated  tactical  situation.  When  combined 
with  the  requisite  ground  elements,  the  result  is  a  balanced,  self-sufficient,  cohesive 
organization  composed  of  air  and  ground  arms  known  as  the  Marine  Air-Ground  Task 
Force  (MAGTF). 

A  task  organized  Aviation  Combat  Element  (ACE)  will  normally  be  formed  to  fuUy 
support  the  MAGTF.  The  ACE  supports  the  MAGTF  with  firepower  and  mobility  it 
would  not  have  otherwise.  The  ACE  is  not  a  permanent  organization,  but  is  organized 
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and  equipped  to  provide  the  aviation  functions  required  to  accomplish  the  assigned 
mission.  The  tasks  required  to  support  the  ACE’s  mission  fall  into  six  functional 
categories:  offensive  air  support,  anti-air  warfare,  assault  support,  air  reconnaissance, 
electronic  warfare,  and  control  of  aircraft  and  missiles. 

Control  of  aircraft  and  missiles  is  defined  as  "the  coordinated  employment  of 
facilities,  equipment,  communications,  procedures,  and  personnel  which  allow  the 
MAGTF  commander  to  plan,  direct,  and  control  the  efforts  of  the  ACE  to  support  the 
accomplislunent  of  the  MAGTF’s  mission."  (FMFM  5-60,  1990,  p.  1-1-2)  According  to 
JCS  Pub  1 ,  command  and  control  is  "the  exercise  of  authority  and  direction  by  a  properly 
designated  commander  over  assigned  forces  in  the  accomplishment  of  his  mission."  (JCS 
Pub  1,  1  April  1989,  p.  76)  Command  includes  "...the  authority  and  responsibility  for 
effectively  employing  available  resources.. .for  the  accomplishment  of  assigned  missions." 
(JCS  Pub  1,  1  April  1989,  p.  76)  Control  is  defined  as  the  "authority  which  may  be  less 
than  full  exercised  by  a  commander  over  part  of  the  activities  of  subordinate  or  other 
organizations."  (JCS  Pub  1,  1  April  1989,  p.  87)  Therefore  "control  of  aircraft  and 
missiles"  is  synonymous  with  "authority  over  aircraft  and  missiles." 

C.  MARINE  AIR  COMMAND  AND  CONTROL  SYSTEM 

The  ACE  commander  exercises  operational  control  over  his  assigned  forces  through 
the  MACCS.  The  MACCS  is  an  integral  pan  of  the  ACE’s  organizational  structure  and 
consists  of  units  specifically  equipped  with  personnel,  facilities,  communications,  and 
trained  in  procedures  to  support  the  command  and  control  of  all  MAGTF  air  operations. 
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The  MACCS  operates  under  the  principle  of  centralized  command  and  decentralized 
control  for  maximum  responsiveness  to  combat  operations. 

The  personnel  and  equipment  required  to  establish  the  MACCS  are  contained 
primarily  in  the  Marine  Air  Control  Group  (MACG)  and  its  subordinate  squadrons.  The 
functional  components  (personnel  and  equipment)  of  the  MACCS  depicted  in  Figure  1 
include: 

•  Tactical  Air  Command  Center  (TACC)  is  the  senior  MAGTF  air  command  and 
control  agency  which  serves  as  the  operational  command  post  of  the  tactical  air 
commander  (TAC),  usually  the  ACE  commander.  The  TAC  and  his  staff  execute 
the  current  air  battle  and  plan  for  the  future  battle  culminating  in  the  publication  of 
the  Air  Tasking  Order  (ATO)  and  appropriate  fragmentation  (FRAG)  orders. 

•  Sector  Antiair  Warfare  Coordinator’s  (SAAWC’s)  facility,  which  is  normally 
colocated  with  the  Tactical  Air  Operations  Center  (TAOC),  is  the  senior  air  defense 
battle  manager  for  the  ACE.  It  provides  the  interface  between  the  TAOC  and 
TACC. 

•  TAOC  and  Early  Waming/Control  (EW/C)  sites  detect,  identify,  and  control  the 
intercept  of  hostile  aircraft  and  missiles. 

•  Direct  Air  Support  Center  (DASC)  processes  immediate  air  support  requests, 
coordinates  aircraft  employment  with  other  supporting  arms,  and  controls  aircraft 
transmitting  its  area  of  responsibility.  A  complete  description  of  the  DASC’s  roles, 
tasks,  inter-agency  relationships  and  information  needs  will  be  discussed  later. 

•  Air  Support  Radar  Team  (ASRT)  provides  day/night  all-weather  control  of  aircraft 
operating  in  support  of  MAGTF  operations. 

•  Subordinate  Command  Posts  (CPs)/Combat  Operation  Centers  (COCs)  provide  the 
primary  control  agency  from  which  Light  Antiaircraft  Missile  (LAAM)  and  Low- 
altitude  Air  Defense  (LAAD)  Battalions  can  direct  and  control  the  HAWK  and 
Stinger  missile  systems. 

•  Marine  Air  Traffic  Control  Squadron  (MATCS)  Detachment  provide  corrmuous  all- 
weather  air  traffic  services  for  expeditionary  airfields  and  remote  lantnig  sites. 
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•  Airborne  Control  Agencies  offer  flexibility  to  op>erate  either  as  an  extension  of  the 
means  of  control  to  functional  control  agencies  (Tactical  Air  Coordinator  (Airborne) 
(TAC(A)),  Helicopter  Coordinator  (Airborne)  (HC(A})),  in  support  of  specific 
ground  units  (Forward  Air  Controller  (Airborne)  (FAC(A))),  or  in  coordination  of 
other  aircraft  (Refueling  Area  Coordinator  (RAC)). 

•  Tactical  Air  Control  Parties  (TACPs)  are  organic  to  the  Ground  Combat  Element 
and  provide  air  liaison  to  land  forces  and  terminal  control  of  aircraft. 

MACCS  agencies  have  no  control  over  aircraft  or  other  units  unless  specifically 

delegated  to  them  by  the  appropriate  commander.  Types  of  control  that  are  usually 

delegated  include: 

•  Command.  The  TACC  is  the  one  MACCS  agency  that  exercises  command. 

•  Air  Direction.  The  authority  to  regulate  the  employment  of  air  assets. 

•  Air  Control.  The  authority  to  direct  the  physical  maneuver  of  air  assets. 

•  Airspace  Control.  The  coordination,  integration  and  regulation  of  airspace. 

•  Terminal  Control.  A  subset  of  control  that  applies  to  the  delivery  of  ordnance, 
cargo,  or  persormel  by  aircraft. 

The  MACCS  will  be  tasked-organized  to  provide  MAGTF  commanders  with  the 
assets  required  for  effective  command,  coordination,  and  control  of  all  MAGTF  air 
operations.  Interagency  relationships  between  the  MACCS  elements  can  be  defined  as 
the  type  of  control  each  agency  exercises  Development  of  the  ATO  is  a  form  of  air 
direction  that  the  ACE  commander  exercises  through  the  TACC.  Air  control  can  be 
thought  of  as  an  instruction  given  to  a  pilot  by  a  control  agency  to  alter  his  course. 
Airspace  control  is  the  authority  to  direct  aircraft  so  the  best  use  is  made  of  a  defined 
area  of  responsibility.  The  DASC  exercises  both  air  control  and  airspace  control  when 
authority  has  been  delegated  to  them.  The  DASC  will  receive  air  direction  via  the  ATO 
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from  the  TACC.  Figure  1  depicts  the  MACCS  and  its  control  relationships  with  the 
various  agencies. 

D.  DIRECT  AIR  SUPPORT  CENTER 
1.  Background 

The  Direct  Air  Support  Center  is  the  principle  air  control  agency  responsible 
for  the  direction  of  air  operations  directly  supporting  ground  forces.  The  DASC  processes 
direct  air  support  requests,  controls  aircraft  in  its  area  of  responsibility,  manages  terminal 
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control  agencies  in  support  of  the  ground  combat  element  (GCE),  and  coordinates  air 
missions  requiring  integration  with  other  supporting  arms. 

The  DASC  functions  in  a  decentralized  mode  of  operation  under  the  command 
of  the  TACC.  It  is  normally  the  first  major  air  control  agency  ashore  and  normally  lands 
with  the  senior  Fire  Support  Coordination  Center  (FSCC)  during  scheduled  or  on-call 
waves.  It  physically  or  electronically  colocates  with  the  senior  FSCC  and  works  closely 
with  this  agency  to  ensure  the  coordination  of  air  support  with  other  supporting  arms. 
The  DASC  maintains  the  capability  to  operate  during  mobile  combat  situations  by 
displacing  by  echelon  to  preserve  operational  continuity.  The  "echelon  DASC"  will  have 
the  capability  to  perform  the  same  tasks  as  the  main  DASC. 

Functional  positions  within  the  DASC  include  directors  and  net  operators. 
Directors  interface  with,  and  control  aircraft.  Net  operator  coordinate  with  agencies 
external  to  the  DASC.  The  functions  and  tasks  performed  by  the  directors  and  net 
operators  within  the  DASC  is  discussed  next. 

2.  Tasks 

The  DASC  provides  direct  air  support  functions  for  the  MAGTF  by  performing 
the  following  tasks: 

*  To  receive  fragmentary  operation  orders  (FRAGOs)  and  ATOs  from  the  TACC  and 
coordinate  preplanned  scheduled  direct  air  support.  The  ATO  and  FRAGOs  are 
normally  received  on  a  daily  basis  but  may  be  modified  as  changes  occur. 
Information  about  these  changes  will  normally  come  via  the  TACC. 

•  To  receive,  process,  and  coordinates  requests  for  immediate  or  on-call  air  support. 
These  requests  will  normally  originate  from  the  supported  ground  combat  clement 
requesting  tactical  air,  assault  support,  or  medical  evacuation.  This  is  one  of  the 
most  critical  tasks  performed  by  the  DASC. 
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•  To  adjust  preplanned  scheduled  aircraft  and  divert  airborne  assets  based  upon 
mission  priority  in  coordination  with  the  senior  FSCC  when  delegated  authority  by 
the  TAC. 

•  To  provide  coordination  in  the  execution  of  direct  air  support  missions  with  other 
supporting  arms  through  the  appropriate  FSCC. 

•  To  coordinate  subordinate  terminal  control  agencies  as  required. 

•  To  receive  and  disseminate  pertinent  tactical  information  reported  by  aircraft 
performing  direct  air  support  missions. 

•  To  provide  aircraft  and  other  air  control  agencies  with  advisory  information  for  the 
safe  conduct  of  flight. 

-  To  monitor,  record,  and  display  information  on  direct  air  support  missions. 

•  To  maintain  friendly  and  enemy  ground  situation  displays,  as  necessary,  to 
coordinate  direct  air  support  missions. 

•  To  provide  information  to  other  MACCS  agencies  concerning  the  friendly  and 
enemy  situation  to  include  aircraft  position. 

•  To  refer  unresolved  conflicts  in  supporting  arms  to  the  fire  support  coordinator  and 
provide  an  operational  point  of  contact  to  ensure  air  support  is  responsive  to  the 
tactical  situation. 

3.  Communication  Links 

In  order  for  the  DASC  to  perform  these  tasks,  rapid  and  reliable 
communication  links  must  be  maintained  with  agencies  external  to  the  DASC.  The 
command  and  control  connectivity  between  the  DASC,  the  aircraft  and  these  external 
agencies  is  accomplished  by  radio.  The  primary  DASC  interagency  relationships  depicted 
in  Figure  2  include: 

•  DASC/TACC.  The  DASC  is  subordinate  to  the  TACC  and  provides  for 
decentralized  control  of  direct  air  support  missions  including  close  air  support 
(CAS),  and  assault  support.  The  TAC  will  ideally  delegate  divert  and  on-call 
launch  authority  of  aircraft  to  the  DASC  to  ensure  minimum  response  times  to 
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MAGTF  requirements.  The  TACC  provides  the  DASC  with  appropriate  ATOs, 
FRAGOs,  aircraft  call-signs,  and  aircraft  availability.  The  DASC  and  the  TACC 
exchange  tactical  information,  intelligence,  and  the  progress  and  effectiveness  of 
direct  air  support  missions. 

•  DASC/FSCC.  Since  the  FSCC  is  the  final  arbitrator  for  all  supporting  arm  conflicts 
the  DASC  and  FSCC  maintain  close  ties.  The  DASC  and  FSCC  must  be  able  to 
exchange  timely  information  on  tactical  information  (fire  support  coordination 
measures,  friendly/  enemy  unit  positions,  etc.),  pertinent  intelligence  data,  status  of 
immediate  air  support  requests,  bomb  damage  assessments,  divert  and  on-call 
launch  decisions,  and  other  prearranged  data  items. 

•  DASC/Antiair  Warfare  (AAW)  Agencies.  TTie  DASC  must  be  able  to  exchange 
tactical  data  information  and  pertinent  friendly  aircraft  location  with  the  appropriate 
AAW  agencies  (TAOC,  LAAD/LAAM  CPs). 

•  DASC/Airbome  Controllers.  The  DASC  must  coordinate  and  exchange  information 
with  airborne  control  agencies  pertaining  to  their  responsibilities. 
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-  DASC/ASRT.  The  ASRT  is  a  terminal  control  agency  subordinate  to  the  DASC 
and  receives  all  tactical  data  information  from  the  DASC. 

•  DASC/TACPs.  The  DASC  receives  and  processes  immediate  air  support  requests 
from  the  terminal  controllers  (Forward  Air  Controllers  (FACs))  and  apprises  the 
TACPs  and  FACs  of  their  status. 

•  DASC/OTHERS.  The  DASC  will  establish  and  maintain  communication  links  with 
other  agencies  as  required.  Examples  of  this  include,  MATCS,  Remotely  Piloted 
Vehicle  (RPV)  Receiving  Station,  and  the  Air  Force  Air  Support  Operations  Center 
(ASOC). 

4.  Current  Operations 

The  DASC  is  a  flexible,  communications  intensive  facility  that  may  be 
configured  to  support  a  variety  of  tactical  situations.  It  is  presently  a  manual  system 
using  procedural  control  methods  and  voice  communication  to  fulflU  its  tasks. 

The  ATO  is  issued  by  the  TACC  and  distributed  to  the  MACCS  elements  on 
a  daily  basis.  This  ATO  may  or  may  not  be  a  re-creation  of  the  Air  Force  ATO.  The 
means  of  distribution  of  the  ATO  may  be  via  message  traffic  through  a  message  center, 
courier,  or  local  area  network.  Considerable  time  is  then  expended  in  processing  and 
disseminating  the  ATO  data  within  the  DASC  and  retransmitting  applicable  ATO  mission 
data  to  the  ASRT  or  TACP’s.  The  DASC  receives  voice  or  message  traffic  whenever  a 
change  to  the  ATO  occurs. 

Requests  for  immediate  air  support  are  transmitted  from  the  TACPs  to  the 
DASC  over  the  voice  only  Tactical  Air  Request  (TAR)  Net.  All  FSCCs  monitor  the  TAR 
net  and  may  disapprove,  or  by  their  silence,  give  consent  to,  the  immediate  air  request 
(Figure  3).  Upon  receipt,  the  DASC  will  concurrently  process  the  request,  and  coordinate 
mission  planning  with  the  colocated  FSCC.  The  DASC  will  fulfill  the  request  by 
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diverting  lower  priority  airborne  aircraft  or  by  launching  on-call  missions.  Each  request 
requires  manual  completion  of  a  specific  form,  must  be  posted  on  display  boards,  and 
transmitted  to  the  TACC.  Upon  completion  of  the  request,  mission  data  is  manually 
recorded  on  the  form  and  disseminated  to  the  TACC  and  FSCC. 

As  all  types  of  operational  message  traffic  increases,  the  DASC’s  operational 


mission  data  becomes  less  current  because  of  the  workload  in  manual  processing, 
dissemination,  transmission  and  posting  of  information. 


Figure  3.  Immediate  Air  Requests 

E.  AIR  TASKING  ORDER 

The  ATO  planning  process  for  tactical  air  operations  is  a  continuous  activity  that 
begins  at  the  senior  MAGTF  level  for  the  Marine  Corps  or  the  joint  force  theater  level 
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in  combined  operations.  The  planning  steps  will  be  treated  genetically,  using  the  Marine 
Corps  as  an  example  (Figure  4).  The  time  sequence,  usually  36  hours  for  the  Marine 
Corps,  would  be  longer  when  considering  the  joint  level.  The  planning  sequence  provides 
background  on  how  the  ATO  is  generated  and  transmitted  by  the  TACC  and  received  and 
processed  by  the  DASC. 

The  MAGTF  commander  develops  the  strategy  and  establishes  the  objectives  for 
the  conduct  of  military  operations  and  apportions  the  available  force  to  the  various  air 
tasks  for  a  specific  period  of  time.  Apportionment  is  usually  expressed  as  a  jjercentage 
of  total  available  assets  assigned  to  the  various  missions  (CAS,  AAW,  etc.)  or  in  terms 
of  priority  by  mission  or  geographic  area.  This  apportionment  guidance  is  based  on  the 
recommendation  from  his  component  commanders  (ACE,  GCE,  etc.)  and  is  promulgated 
in  the  apportionment  guidance. 

The  ACE  commander  reviews  his  assets  and  allocates  them  in  terms  of  sorties 
according  to  actual  numbei  of  aircraft  by  t)q>e  for  each  mission  category  consistent  with 
the  apportionment  guidance.  The  future  battle  cell  (FBC)  in  the  TACC  is  responsible  for 
developing  the  detailed  plans  of  the  ATO  based  on  the  apportionment  and  allocation  of 
resources.  The  ground  combat  element  provides  the  FBC  with  a  prioritized  target  list  for 
air  interdiction  targets  and  any  additional  preplanned  requests  to  include  a  needed 
preplanned/immediate  missions  mix.  The  FBC  considers  the  weather,  enemy  threat, 
availability  of  assigned  forces  and  weapons,  and  target  selection  when  developing  the 
plan.  Sorties  in  excess  of  MAGTF  direct  support  requirements  will  be  provided  to  the 
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Joint  Force  Commander  for  joint  force  tasking.  The  results  of  this  planning  process  are 
disseminated  as  the  ATO. 

Although  there  is  no  specific  format  for  the  ATO,  the  ATO  provides  the  mission 
details,  special  instructions,  general  information  and  remarks  required  by  the  subordinate 
units  to  execute  their  assigned  tasks.  The  ATO  will  normally  be  transmitted  in  message 
text  format  (USMTF)  or  marine  tactical  standard  (MTS).  The  USMTF  ATO  message  is 
further  discussed  Chapter  III  and  is  listed  in  Appendix  C. 

Upon  receipt  of  the  ATO,  aircraft  groups  generate  FRAGOs  assigning  specific 
missions  to  squadrons  and  aircrews.  Control  agencies  review,  manipulate,  and  manually 
record  the  ATO  onto  report  in/out  (RJO)  forms/logs  and  time-lines  in  preparation  of 
controlling  and  directing  the  aircraft. 


F.  LESSONS  LEARNED  FROM  OPERATION  DESERT  STORM 

The  IDASC  (Improved  DASC)  Users  Conference  was  held  8-12  April,  1991  at 
Mare  Island,  California  following  Operation  Desert  Storm  primarily  to  "get  a  consensus 
of  the  air  support  control  community  on  the  priority  and  nature  of  proposed  requirements 
(IDASC  project)."  (Report  of  Travel/Conference,  1  May  1991,  p.  1)  Receipt  of  the  ATO 
was  a  main  discussion  item  of  the  air  support  control  community  at  this  conference  as  the 
following  item  reflects: 

•  "SUBJECT:  RECEIPT  OF  THE  ATO 

*  DISCUSSION:  The  Joint  ATO,  issued  by  the  Air  Force  was  upwards  of  700  pages 
long  and  originally  was  received  via  the  Division  Communications  Center.  Later, 
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Figure  4.  ATO  Planning  Process 


it  was  scrubbed  by  the  TACC  and  sent  to  the  DASC  via  LAN.  Received  by  the 
DASC  on  a  UYQ-85,  it  arrived  as  two  documents,  a  fixed  wing  and  helicopter 
ATO.  The  scrubbed  version,  however,  did  not  include  other  services  aircraft. 
While  the  large  joint  version  was  still  available  via  the  communications  center, 
significant  effort  was  necessary  to  glean  out  the  applicable  missions  from  this 
unabridged  version.  WTiile  a  standard  MTF  format  was  used,  some  Marines  stated 
that  some  standardization  still  needed  to  be  set  down. 

•  IMPACT:  The  DASC  needs  the  ATO  in  a  timely  manner  and  in  a  useful  format. 
Consistent,  successful  receipt  via  the  LAN  on  Desert  Storm  seems  to  suggest  that 
this  is  a  good  way  to  receive  the  ATO  provided  that  the  LAN  is  available.  The 
other  ways  of  receiving  the  ATO  (courier,  teletype,  tactical  FAX)  are  still  available 
if  a  LAN  isn’t. 

•  Ideally,  the  DASC  would  need  to  be  capable  of  receiving  the  ATO  either  di’^ectly 
from  the  joint  level  or  from  the  Marine  Corps  TACC.  In  either  case  we  would  like 
to  be  able  to  manipulate  the  ATO  in  such  a  form  as  to  be  readily  usable  to  the 
aircraft  directors,  the  SAD  and  anyone  else  who  needs  it.  (Many  man-hours  are 
spent  "busting  the  frag:"  copying  the  applicable  portions  of  the  ATO  onto  RIO 
sheets  and/or  making  up  time-lines  so  that  it  is  usable) 
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*  If  we  have  the  luxury  of  receiving  the  ATO  digitally,  a  manipulative  program  in  the 
UYK-85  could  be  used  to  separate  out  helos  from  fixed  wing,  arrange  the 
information  into  kinds  of  columns  that  we  like  to  see,  filter  out  unnecessary 
information,  make  up  time  lines  to  show  mission  groupings,  and  generally  save  time 
and  effort.  One  Marine  using  such  a  program  could  prepare  RIO  sheets  for  the 
directors  and  time  lines  for  the  SAD  in  minutes.  For  record  purposes,  information 
could  be  quickly  extracted  by  mission  type,  ordnance  type,  aircraft  type,  etc.,  and 
sent  to  the  TACC  without  taking  up  a  lot  of  valuable  time..."  (Desert  Storm  Initial 
Debrief  Synopsis,  9  April  1991,  p.  6) 

The  users  identified  the  following  required  capabilities  during  Phase  n  (selected 
automation)  of  the  IDASC  project  in  order  of  priority; 

1 .  Receive  and  print  out  the  ATO  in  MTF  or  MTS  format. 

2.  Manipulate  the  ATO  into  formats  desired  by  the  user. 

3.  Receive  and  print  out  PLRS  information. 

4.  Send,  receive  and  print  out  DCT  messages. 

5.  Automatically  record  and  file  Tactical  Air  Request  (TAR’s),  Bomb 
Damage  Assessments  (BDA’s)  and  other  DASC  related  information. 

6.  Extract  statistical  information  from  automated  files. 

G.  SUMMARY 

It  is  necessary  to  realize  that  the  Marine  Air  Command  and  Control  System  is 
fundamentally  a  tool  that  decision  makers  use.  It  is  a  collection  of  equipment,  personnel, 
and  procedures  that  help  the  ACE  commander  gather,  process,  and  disseminate 
information.  Within  the  present  DASC,  coordination  of  air  support  requests  with  the 
FSCC,  the  receipt,  storage,  display,  manipulation,  and  dissemination  of  the  ATO  and 
FRAGOs,  and  retrial  and  display  of  operational  data  are  largely  manual.  The  system  is 
rapidly  becoming  deficient  in  its  ability  to  perform  its  tasks.  An  increasing  amount  of 
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information  has  generated  the  need  for  selective  automation  of  parts  of  the  system.  Given 
the  current  DASC  and  the  related  ATO  operations,  what  aspects  of  the  overall  process  can 
be  automated  effectively?  The  next  chapter  specifies  requirements  which  address  this 
question. 
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m.  DASC/ATO  REQUIREMENTS 


A.  GENERAL 

This  chapter  discusses  the  following  issues  involved  when  designing  a  database 
processing  system  for  the  DASC; 

•  information  processing  requirements 

•  hardware  concepts  and  problems  in  the  battlefield  environment 

•  man-machine  interface  considerations 

•  data  communications 

-  interoperability 

•  system  security  issues 

Background  information  about  the  IDASC  project  will  be  summarized  first  to  show 
the  constraints  and  scope  of  the  needed  database  ^plicati^n.  Internal  and  external 
interaction  requirements  and  constraints  of  the  system  will  be  briefly  discussed  to 
determine  the  demands  placed  on  the  design  of  the  equipment  and  the  applications.  The 
information  flow  requirements  discussed  last  will  serve  as  a  blueprint  for  database  design 
and  implementation  addressed  in  Chapters  IV  and  V. 

B.  IDASC  PROJECT  SUMMARY 

The  IDASC  is  the  designation  given  to  the  AN/rSQ-155(V)  operations  shelter.  The 
shelter  houses  the  persoruiel  and  equipement  required  of  the  DASC  to  perform  its  mission. 


To  avoid  confusion  because  of  pending  modifications,  the  IDASC  will  be  referred  to  as 
the  AN/TSQ-155  when  in  reference  to  the  system  or  DASC  when  implying  the 
operational  function.  The  DASC  supporting  system  prior  to  the  AN^SQ-155  was  fielded 
during  the  1960’s  and  was  designated  the  AN/TSQ-122.  The  AN/TSQ-122  was  unable 
to  satisfy  increasing  operational  requirements  and  was  fully  replaced  in  1989  by  the 
AN/TSQ-155.  The  acquisition  was  initiated  to  satisfy  requirements  exclusive  to  the  U.S. 
Marine  Corps.  There  was  no  joint  or  foreign  service  participation.  Ehiring  May  1989, 
the  Naval  Electronics  Systems  Engineering  Center  (NAVELEXCEN)  was  tasked  to  act 
as  the  In-Service  Engineering  Agent  (ISEA)  for  the  IDASC  improvement  program.  After 
reviewing  operational  effectiveness,  it  was  determined  that  operational  deficiencies  existed 
and  the  Required  Operational  Capability  for  the  DASC  was  revised  leading  to  a  phased 
system  upgrade. 

Phase  1  modifications  to  the  AN/rSQ-155  are  near  completion.  Phase  n  (selected 
automation)  and  phase  in  (downsizing/improved  mobility)  upgrades  will  be  accomplished 
concurrently  by  coordinated  design/developmental  tasks  that  will  create  a  new  entity  for 
the  DASC,  a  vehicle  mounted  shelter  with  an  integrated  command  post  extension  tent  and 
equipment  that  will  provide  automated  capability.  The  automated  capability  improvement 
will  be  compatible  with  and  interchangeable  between  the  "Mobile  DASC"  and  the 
AN/rSQ-155. 

A  primary  goal  is  to  populate  the  DASC  with  Non-Developmental  Item  (NDI)  or 
off  the  shelf  computer  equipment  and  software.  The  system  will  use  hardware  from  the 
Marine  Tactical  Command  and  Control  System  (MTACCS)  Common  Hardware  System 


22 


(MCHS)  and  will  consist  of  rugged  computers  capable  of  handling  a  large  volume  of 
information.  The  DASC  computer  terminal  will  be  capable  of  interfacing  with  a  variety 
of  communications  equipment  to  include  tactical  radios,  tactical  switches,  tactical  FAX, 
and  tactical  LANs. 

The  DASC  system  will  incorporate  software  from  the  MTACCS  Common 
Application  Support  Software  (MCASS).  System  software  will  provide  the  DASC  with 
a  set  of  automated  tools  to  assist  in  the  performance  of  its  functions.  These  tools  should 
have  the  following  capabilities:  word  processing,  message  preparation  and  processing, 
tactical  information  database,  digital  message  management  system,  overlay  generation  and 
distribution,  database  management  system,  database  query  crpability,  and  hard  copy  text 
and  graphics.  These  tools  will  enable  the  DASC  to  fulfill  the  user  requirements  of 
updating,  displaying,  and  controlling  the  ATO  and  DASC  related  information  from 
automated  files.  Application  software  will  reflect  the  specific  requirements  of  the  DASC 
and  be  capable  of  tunning  on  the  system  hardware  and  use  system  software.  Additionally, 
each  operator  requires  a  position  which  provides  a  workstation  and  allows  individual 
access  to  intercommunications  and  common  display  information.  (Draft  ROC,  p.  11) 

C.  BATTLEFIELD  REQUIREMENTS 

The  hardware  and  software  used  by  the  DASC  must  be  able  to  operate  in  all  combat 
environmental  conditions.  It  must  be  capable  of  operating  in  a  tent  or  open  field  while 
mounted  in  military  vehicles,  and  be  transportable  with  ruggedized  carrying/shyping 
boxes.  Physical  environment  factors  to  be  considered  include  temperature,  humidity,  sand 
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and  dust,  air  pressure,  shock  and  vibration,  rain,  fog,  and  salt  water.  Furthermore, 
electromagnetic  pulse  (EMP)  and  interference,  as  well  as  radiation  security  (TEMPEST) 
standards  must  be  met.  Finally  materials  used  must  be  resistant  to  chemical  agents  and 
chemical  decontaminants.  Human  factors  engineering  must  be  implied  to  allow  human 
operators  in  all  mission-oriented  protective  postures  to  use  the  machines  in  the  battlefield 
environment.  The  size  and  weight  of  the  components  should  allow  for  ’one-marine 
carry'.  The  system  should  have  visual  indicators  and  messages  easily  readable  in  all 
ambient  light  conditions.  The  storage  hardware  must  be  capable  of  rapid  emergency 
destmction  to  enable  protection  of  classified  data.  Redundancy  both  in  data  storage  and 
power  requirements  must  also  be  planned.  These  battlefield  environmental  constraints 
will  have  an  effect  on  the  physical  design  of  the  hardware  as  well  as  the  architecture  of 
the  whole  system  including  its  interfaces. 

D.  SYSTEM  INTERFACES 

The  DASC  must  interface  with  agencies  internal  and  external  to  the  MAGTF.  In 
order  to  fulfill  these  requirements,  numerous  intra/intcroperability  interface  networks  have 
been  constructed;  however,  some  interoperability  requirements  arc  projected  as  future 
requirements. 

The  system  must  also  interface  with  the  required  MACCS  and  MTACCS  agencies. 
Projected  interoperability  interfaces  include  elements  of  the  Naval  Tactical  Air  Control 
System  (NTACS),  the  Air  Force  Tactical  Air  Control  System  (TACS),  the  Army 
Command  and  Control  System  (ACCS),  and  allied  air  support  control  units  as  required. 
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The  DASC  system  will  affect  interoperability  in  accordance  with  the  Marine  Tactical 
System  Technical  Interface  Design  Plan  (MTS  TIPD)  and  United  States  Message  Text 
Format  (USMTF). 

1.  Marine  Tactical  System 

The  MTS  TIDP  provides  USMC  Tactical  Data  Systems  (TDSs)  with 
intraoperability  message,  data  elements,  and  protocol  standards.  The  interface  design  plan 
decomposes  Marine  Corps  Command  and  Control  Facilities  (C2FACs)  of  the  MTACCS 
interface  requirements  into  specific  data  link  protocol  and  message/data  implementation 
requirements.  It  also  provides  the  data  element  standard  for  data  field  identifiers  (DFIs), 
data  use  identifiers  (DUIs),  and  data  items  (DIs)  that  support  the  MTS  standards.  The 
message  standards  in  volume  IV  of  the  TIDP  contains  approved  Marine  Corps  messages 
with  information  on  message  purpose,  structure,  data  content,  and  format.  The 
transmission  format  (physical  order  and  sequence  of  the  fields)  are  presented  on  text 
information  sheets  within  the  TIDP.  The  MTS  Message  Formatting  protocol  provides 
message  formatting  that  allows  the  system  to  be  independent  of  the  communications 
system. 

2.  Message  Text  Format 

The  USMTF  program  is  designed  to  provide  a  uniform  reporting  procedure  to 
be  used  in  all  defense  conditions  and  to  reduce  the  time  required  to  draft,  transmit, 
analyze,  interpret,  and  process  messages.  The  message  text  format  (MTF)  program 
improves  information  exchange  by  producing  messages  which  are  both  human  readable 


and  machine  compatible.  The  program  also  has  the  objective  of  facilitating  the  exchange 
of  information  between  the  United  States  and  Allied  commands  and  reducing  or 
eliminating  dual  reporting  by  US  units  when  they  operate  with  Allied  command/units. 
The  MTF  program  describes  what  is  in  reality  an  artificial  language  with  its  own  definite 
structure,  vocabulary,  and  syntax.  The  MTF  ATO  message  format  is  listed  in  Appendix 
C. 

3.  Communications 

Communications  requirement  considerations  include  capacity,  response  time, 
connecting  and  addressing,  integrity,  control,  security,  and  transmission  medium.  The 
demand  for  communication  will  not  be  constant  but  the  demands  for  data  transmission 
capacity  and  response  time  must  be  met  by  the  communications  system.  Connecting  and 
addressing  protocols  must  provide  a  means  for  identifying  the  intended  recipient  of  a 
transmission.  The  transmission  medium  must  preserve  the  integrity  of  the  information 
it  handles.  Control  protocols  must  be  applied  to  channel  and  transmission  medium 
between  computer-based  information  systems.  The  security  of  the  information  must  be 
preserved  by  the  communication  system.  Redundancy  in  the  transmission  medium  must 
be  planned.  This  redundancy  may  be  single  or  multi-channel  radio,  satellite 
communications,  copper  cables  or  fiber  optics. 
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E.  MAN  MACHINE  INTERFACE 


Rice  states  that  "the  design  of  the  ...  man-machine  interface  (MMI)  will  be  crucial 
to  the  efficient  working  of  the  system  ...  it  provides  the  user  with  a  window  through 
which  he  may  view  the  system  and  a  set  of  controls  to  enable  him  to  drive  it."  (Rice,  p. 
82)  Simple  interfaces  consist  of  a  way  to  insert/extract  information  into/from  the  system, 
and  to  direct  the  system  what  actions  to  take.  The  MMI  includes  the  hardware  and  the 
software  for  this  process.  The  dialogue  used  in  this  process  determines  how  "user- 
friendly"  the  system  is. 

Input  devices  consist  of  keyboards  and  pointing  devices.  A  pointing  device  such 
as  a  tracker  baU  or  mouse  moves  a  symbol  on  the  display  to  a  desired  position.  Pointing 
to  the  desired  position  on  the  screen  itself  with  a  finger  or  instrument  is  another  type  of 
input. 

Output  devices  include  either  temporary  or  permanent  display  units.  Temporary 
displays  consist  of  visual  display  units  such  as  cathode  ray  tubes  (CRT),  liquid  crystal 
displays  (LCD),  gas  plasma  display,  and  projected  displays.  Permanent  displays  which 
deliver  a  hard  copy  may  be  either  printers  or  plotters.  Printers  are  usually  limited  to  text 
or  simple  graphics  while  plotters  can  produce  images  along  an  x  and  y  axis.  Laser 
printers  combine  the  qualities  of  both  a  printer  and  a  plotter. 

Other  interface  technologies  under  consideration  are  voice  recognition  for  input  and 
speech  synthesizers  for  output. 

The  design  of  the  dialogue  between  man  and  machine  will  determine  how  the  user 
interacts  with  the  system.  The  MMI  should  be  easy  to  use  for  both  the  inexperienced  and 
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the  familiar  user,  consistent,  and  optimized  for  the  task  being  performed.  (Rice,  p.  96) 
A  context-sensitive  "help"  key  which  explains  the  task  being  performed  is  an  example  of 
this  trait.  Consistency  standardization  refers  to  the  way  tasks  are  to  be  performed.  A 
simplified  example  of  inconsistency  would  be  imputing  ’Y’  or  ’N’  in  one  application 
program  while  requiring  ’YES’  and  ’NO’  in  another.  Pointing  devices  should  also 
maintain  consistent  operations.  Optimization  for  the  task  being  performed  means  that  the 
user  should  not  have  to  access  a  large  number  of  displays  to  perform  his  job. 

Styles  of  MMI  that  conform  to  the  requirements  above  include  a  keyboard  based 
MMI,  a  touchscreen  based  MMI,  and  the  windows,  icons,  menus  and  pointer  (WIMP) 
approach  to  MMI.  (Rice,  p.  98)  Menu  selection  refers  to  a  range  of  choices  presented  to 
the  user  on  the  screen.  The  input  by  the  user  will  lead  to  other  menus  or  to  the  task 
requiring  performance  such  as  entering  form  information.  These  layers  of  menus  are 
referred  to  as  the  depth  of  the  application  and  may  be  described  as  a  tree  structure. 
Experienced  users  should  be  able  to  jump  between  layers,  while  a  user  who  finds  himself 
confused  about  his  location  in  the  menu  dialogue  should  be  able  to  return  directly  to  the 
main  menu. 

Keyboard  based  MMI  are  useful  in  data  entry  systems.  A  menu  can  lead  the  user 
to  the  correct  form  and  then  a  form  layout  can  assist  the  user  in  entering  information. 
Shaded  areas  can  highlight  required  inputs. 

Touch  screens  can  be  interchanged  or  incorporated  with  keyboard  based  MMIs, 
using  graphical  representations  that  prompt  the  user  to  touch  the  screen  for  the  desired 
result. 
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Tlie  WIMP  approach  to  MMI  offers  benefits  which  include  consistency  and  multiple 
tasking.  Windows  are  an  area  of  the  screen  dedicated  to  a  particular  task.  Icons 
graphically  represent  a  resource  or  action  to  be  preformed.  When  combined,  they 
approximate  the  way  a  user  may  organize  his  tasks. 

The  following  examples  of  consistency  include  retrieval  and  saving  of  documents. 
All  files  are  opened  by  pointing  to  an  associated  icon.  Saving  a  file  is  accomplished  by 
’dragging’  it  to  a  file  cabinet  icon  and  then  clicking  a  button  on  the  mouse  to  indicate  the 
document  is  to  be  saved. 

Multiple  tasking  involves  being  able  to  work  on  two  or  more  applications  at  the 
same  time.  For  example,  while  working  on  a  word  processing  document,  the  user  may 
open  a  window,  retrieve  data  from  a  spreadsheet  and  then  ’cut  and  paste’  this  information 
into  the  original  document.  This  example  of  multiple  tasking  demonstrates  one  of  the 
advantages  of  the  WIMP  or  graphical  user  interface  (GUI)  approach  to  MMIs. 

The  choice  of  MMI  will  be  determined  by  the  required  tasks  and  battlefield 
environment.  Because  the  users  in  the  air  support  community  are  often  resistant  to 
automation,  these  design  decisions  are  critical  to  the  acceptance  of  the  entire  system. 
Automation  must  both  improve  efficiency  through  user  friendliness,  and  provide  useful 
information.  MCTSSA,  representing  the  user  community,  must  stress  the  importance  of 
user  friendliness  and  insure  user  involvement  with  the  designers,  developers  and 
programmers  of  the  MMI. 
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F.  INFORMATION  FLOW  REQUIREMENTS 

Although  the  DASC  consists  of  many  crew  members  performing  separate  functions, 
we  wUl  treat  the  DASC  as  a  "black  box"  and  concern  ourselves  with  the  external 
information  flow  of  the  DASC  rather  than  the  internal  coordination  of  the  DASC  crew. 
The  DASC  crew  will  interact  with  different  applications  designed  for  their  specific 
functions.  The  information  flow  of  the  DASC  that  pertains  to  the  user  requirements 
defined  in  Chapter  n  is  depicted  in  Figure  5  and  includes:  the  ATO,  mission  requests, 
mission  status,  aircraft  status,  and  batde  damage  assessments.  Each  is  considered  in  turn. 
The  appropriate  forms  are  displayed  in  Appendix  3. 


Figure  5.  DASC  Information  Flow 
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1.  ATO 


The  ATO  is  received  by  the  DASC  daily.  Updates  or  changes  to  the  ATO  can 
be  received  at  any  time.  The  MTS  message  includes  the  effective  time  period,  tasked 
unit(s),  and  basic  mission  information:  mission  number,  request  number,  priority,  mission 
type,  time  on  and  off  target,  alert  status,  location,  callsign,  number  and  type  of  aircraft, 
ordanance  type,  IFF/SIF  mode  and  code,  and  time  and  target  location. 

2.  Mission  Status 

Mission  status  refers  to  the  information  that  an  appropriate  MTACCS  agency 
sends  or  requests  on  aircraft  assignment  data.  The  status  may  pertain  to  preplanned,  on- 
call,  or  immediate  missions.  The  information  may  pertain  to  any  data  on  the  ATO. 

3.  Mission  Requests 

Requests  to  the  DASC  for  direct  air  support  can  come  in  the  form  of  tactical 
air  requests  or  assault  support  requests.  Voice  communications  discussed  in  current 
operations  use  the  JTAR  or  ASR  forms.  MTF  message  standards  utilize  the  Air  Support 
Request  (AIRSUPREQ)  format.  The  DASC  may  assign  subordinate  controlling  agencies 
mission  data  and  brief  the  aircrew  using  the  9-Iine  brief  format. 

4.  Aircraft  Status 

Aircraft  status/availability  reports  are  made  to  the  DASC  pertaining  to  aircraft 
in  a  strip  alert  status.  If  the  DASC  has  launch  authority  of  the  aircraft,  information  would 
include  number  and  type  of  aircraft  available  during  specific  time  periods  with  specific 
ordnance  and  strip  alert  times. 
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5.  Battle  Damage  Assessment 


The  purpose  of  the  BDA  is  to  convey  the  pilots’  or  controllers’  damage 
assessment,  ordnance  expended  and  ordnance  remaining.  The  DASC  receives  the 
infonnation  and  relays  it  to  the  appropriate  MTACCS  agency. 

6.  Reports 

The  DASC  may  be  required  to  submit  operational  summary  reports  based  on 
the  operational  events  during  a  specified  period. 

G.  SUMMARY 

The  DASC  system  requirements  discussed  in  this  chapter  defined  the  computer 
hardware,  software,  security  and  communications  considerations  that  require  attention 
when  designing  systems  that  can  survive  on  the  battlefield.  By  establishing  the 
information  exchange  requirement  of  the  users  as  applied  to  the  ATO,  we  are  now  able 
to  look  at  database  processing  alternatives  for  developing  a  database  application  for  the 
DASC. 
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IV.  DASC  DATABASE  APPLICATION 


A.  GENERAL 

The  user  requirements  and  information  flow  discussed  in  the  previous  chapters  will 
provide  the  basis  for  the  logical  database  design  developed  in  this  chapter.  The  Entity- 
Relationship  (E-R)  approach  is  utilized  to  develop  the  logical  database  design.  The  data 
is  normalized  using  an  E-R  modeling  tool.  The  use  of  these  methods  vvill  demonstrate 
the  potential  for  designing  and  implementing  a  relational  database  application  within  the 
DASC. 

B.  DATABASE  OVERVIEW 

Database  technology  was  developed  to  overcome  the  limitations  of  file  processing 
systems.  In  database  systems,  all  application  data  are  stored  in  a  single  repository  called 
a  database.  (Kroenke,  p.  10)  It  is  a  collection  of  related  data  designed  and  built  for  a 
specific  purpose,  intended  for  use  by  a  known  group  of  users,  representing  some  aspect 
of  the  real  world.  Database  processing  eliminates  the  dependency  of  programs  on  specific 
file  formats  which  cannot  be  shared  easfly  by  other  programs.  DB  processing  allows 
different  users  to  share  the  same  data  thus  minimizing  duplication  and  update  problems 
caused  by  redundant  data  in  file  processing  systems.  Unlike  file  processing  programs, 
database  processing  programs  do  not  require  file  and  record  formats.  (Kroenke,  1987,  p. 
11)  File  formats  are  stored  in  the  database  and  accessed  by  a  database  management 
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system  (DBMS).  This  arrangement  of  data,  called  program/data  independence,  is  the 
primary  objective  of  a  DBMS. 

Database  applications  are  developed  so  users  in  different  functional  areas  can 
retrieve  information  from  a  common  database  without  interfering  with  one  another. 
Database  systems  provide  mechanisms  for  updating,  displaying,  and  controlling  the  data. 

A  database  model  is  a  representation  of  a  physical  database.  It  shows  the  physical 
files,  the  access  paths  between  the  files,  and  the  data  items  in  each  file.  Database  models 
are  defined  by  the  way  data  is  organized,  stored,  and  manipulated.  Traditional  file 
processing  systems  use  flat  files  where  relations  between  files  are  defined  by  the 
application  programmer.  The  emergence  of  DBMSs  led  to  different  concepts  in  database 
architecture,  and  the  way  data  is  linked  to  the  database  and  the  application. 

The  primary  database  models  are  the  hierarchical,  network,  and  relational  models. 
In  the  hierarchical  and  network  models,  the  application  programmer  must  know  the 
physical  structure  in  order  to  navigate  through  the  database.  This  structure  can  become 
very  complex  to  learn  and  is  quite  demanding  on  the  user  and/or  programmer  interacting 
with  the  database.  The  conceptual  structure  matches  the  physical  structure  tying  the  data 
to  th*;  application.  This  results  in  a  high  level  of  maintenance  because  changes  in  the 
application  data  requirements  force  changes  in  the  defined  data  structures.  (Brackett,  1987, 
p.  6)  These  weaknesses  have  led  to  a  third  method  of  data  modeling  based  on  relational 
theory. 

Relational  database  architecture  is  an  environment  in  which  data  are  viewed  as 
tables,  or  relations,and  multiple  tables  can  be  associated  or  related  to  one  another  based 
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on  common  data  items  or  fields  within  tlie  tables.  The  physical  relationships  are  defined 
at  execution  time  based  on  the  application  needs.  This  model  contrasts  with  the 
hierarchial  or  network  models  which  require  pointers  or  links  in  each  data  record.  Since 
there  are  no  predefined  relationships  in  relational  databases,  the  structural  detail  is 
minimized.  This  results  in  lower  database  maintenance,  making  it  easier  to  control 
database  changes,  and  provides  flexibility  by  facilitating  the  definition  of  dynamic  logical 
relationships  (Brackett,  1987,  p.  5-6).  Reports  or  processes  can  be  added  without  having 
to  modify  the  structure,  and  changes  made  to  a  data  item  will  be  reflected  in  every  related 
record. 

Knowledge  of  relational  model  terminology  will  assist  in  understanding  the  logical 
database  design  presented  below.  The  relational  data  model  files  appear  as  flat  files,  or 
tables  to  the  users.  A  relation  is  a  table  containing  data  about  an  entity  or  object  that 
obeys  certain  rules.  An  entity  is  a  real  world  thing.  Each  relation  deals  with  a  single 
entity  and  each  row  in  the  relation  is  an  instance  or  occurrence  of  an  entity.  A  tuple  is 
a  row  in  the  table,  an  attribute  is  a  column.  There  is  no  order  to  the  tuples  and  attributes. 
Each  attribute  has  a  domain  of  values  which  can  be  assigned  to  any  instance  of  an 
attribute.  A  key  is  a  group  of  one  or  more  attributes  that  uniquely  identifies  a  row.  The 
primary  key  is  a  unique  identifier  for  the  table.  A  foreign  key  is  an  anribute  on  a 
relation  that  contains  the  primary  key  of  another  relation  in  order  to  relate  one  table  to 
another.  Figure  6  is  an  example  of  a  relation. 
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Figure  6.  Example  of  a  Relation 

C,  DATABASE  DESIGN 


The  goal  of  the  design  phase  is  to  develop  a  model  for  one  or  more  applications 
that  will  support  current  and  future  operations.  Database  design  includes  the  detinition 
of  tables,  attributes,  and  relationships  among  tables.  The  design  methodology  used  in  this 
thesis  is  summarized  in  Figure  7. 

The  schema  is  a  formal  definition  of  the  logical  records  that  make  up  the  database 
and  the  ways  that  relationships  among  records  are  represented.  Logical  database  design 
transforms  the  formal  representation  of  entities  and  their  relationships,  called  a  conceptual 
schema,  into  a  processable  schema  for  a  given  system  application.  TTte  logical  data 
structure  (LDS)  is  a  graphical  depiction  of  the  four  components:  entity,  attribute, 
identifier,  and  relationship.  The  identifier  describes  the  entity,  attribute,  or  relationship 
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Figur«  7.  Database  Design  Process 


(e.g.,  LOCN  identifies  an  attribute  in  Figure  6).  A  collection  of  LDSs  describing  the 
conceptual  information  structure  is  determined  by  the  user.  For  the  DASC  application, 
the  database  requirements  defined  in  the  Information  Flow  Requirements  section  of 
Chapter  HI  require  that  the  user  be  able  to  receive  the  ATO,  to  archive  and  extract 
information  from  it,  and  manipulate  it  into  desired  formats.  The  ability  to  record  and  file 
immediate  requests,  BDAs,  and  other  DASC  related  information,  and  to  query  the 
database  to  extract  statistical  information  is  also  required.  Entity-Relationship  modeling, 
a  top  down  approach  to  data  modeling,  helps  the  designer  to  capture  data  requirements 
and  transform  them  into  a  logical  data  structure  and  user  schema. 


1.  Entity-Relationship  Model 

The  Entity-Relationship  (E-R)  approach  is  unique  among  database  design 
techniques  in  that  it  can  be  used  to  design  a  database  independent  of  the  underlying 
database  model  (hierarchical,  network,  relational).  It  is  based  on  a  theoretical  foundation 
of  relational  algebra,  and  aids  in  communication  between  designers  and  users.  The  E-R 
modeling  steps  are: 

1 .  classification  of  entities  and  attributes 

2.  identification  of  generalization  hierarchies 

3.  determination  of  the  relationships  among  the  entities 

4.  definition  of  the  mapping  cardinality  between  each  relationship  and  entity. 

(Teorey,  1990,  p.  55) 

The  E-R  model  uses  entities  to  represent  a  real  world  thing,  object,  or  concept 
(e.g.,  ATO).  Entities  contain  descriptive  information  called  attributes  (e.g.,  ATO  contains 
Start  Time,  and  Stop  Time).  Attributes  that  may  be  repeated  in  an  entity  are  called 
multivalue  J  atir  butes,  and  will  be  classified  as  separate  entities  (e.g.,  ATO  has  a  repeating 
ATO  Mission  field,  will  be  decomposed  into  a  separate  ATO  Mission  entity).  Attributes 
should  be  attached  to  the  entity  they  best  describe.  An  entity  can  usually  be  described 
by  a  noun.  If  one  entity  is  dependent  on  the  existence  of  another  entity  (e.g..  Mission 
Data  is  dependent  upon  ATO),  then  that  entity  is  described  as  a  weak  entity.  A  gerund 
is  a  relationship  converted  to  an  entity  (e.g.,  customer  ships  a  product,  but  the  shipping 
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is  done  by  clerics).  If  entities  relate  to  themselves  {t.g.,  per son-rmnvtd-per son),  then  the 
relationship  is  called  recursive. 

A  relationship  is  an  association  between  two  or  more  entities.  Relationships 
are  usually  described  by  verbs  in  the  E-R  diagram  (e  g.,  ATO  contains  Mission  Data). 
The  degree  of  a  relationship  is  the  number  of  entities  associated  with  the  relationship. 
A  relationship  with  n  associated  entities  is  called  n-ary  (e.g.,  unary  (1),  binary  (2),  and 
ternary  (3)).  An  entity  is  a  ternary  relationship  if  an  instance  of  an  entity  can  be 
associated  with  one  instance  of  each  of  two  associated  entities.  An  example  is  the  three 
entities  Mission,  JTAR,  and  Unit  associated  by  the  relationship  "requests". 

Values  associated  with  the  connectivity  between  entities  are  "one"  or  "many". 
The  number  associated  with  the  term  "many"  is  called  the  cardinality  of  the  connectivity. 
Functional  dependency  refers  to  the  relationship  between  attributes.  If,  when  given  a 
value  of  attribute  x,  one  can  determine  the  value  of  attribute  y,  then  y  is  said  to  be 
functionally  dependent  on  x.  When  two  attributes  functionally  determine  each  other,  a 
1 : 1  relationship  occurs  (e.g.,  Control  Agency  determines  Callsign,  and  Callsign  determines 
Control  Agency).  If  one  attribute  functionally  determines  another  but  not  the  reverse,  a 
1;M  relationship  occurs  (e.g.,  Callsign  detemiines  Mission  Number,  but  Mission  Number 
does  not  determine  Callsign).  Finally,  if  neither  attribute  is  functionally  dependent  on  the 
other,  a  M:M  relationship  occurs  (e.g..  Mission  Number  and  Request  Number  do  not 
determine  each  other).  (Kroenke,  1987,  p.  163) 

Participation  rules  may  also  pertain  between  entities.  Obligatory  participation 
requires  that  every  instance  of  an  entity  must  participate  in  a  relationship  (e.g.,  all  BDAs 
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must  be  assigned  to  a  Target).  Non-obligatory  participation  is  an  instance  of  an  entity 
mot  needed  to  participate  in  a  relationship  (i.e.  a  BDA  may  exist  with  no  JTARs).  A 
generalization/specialization  {ISA)  occurs  in  a  relationship  when  an  entity  is  partitioned 
by  different  instances  of  a  common  attribute.  An  example  is  the  entities  Mission  Location 
and  Target  Location  which  share  the  common  attribute  Location,  but  have  distinct 
attributes  associated  only  with  that  generalization/specialization  (e.g..  Mission  Location 
has  the  attribute  Location  Type,  while  Target  Location  has  the  attribute  Target  Type).  In 
the  example  above,  ATO  Mission  can  contain  either  a  Target  Location  or  a  Mission 
Location. 

When  translating  the  E-R  model  to  the  relational  approach,  each  entity 
becomes  a  table,  each  attribute  becomes  a  column  in  the  table,  the  unique  identifier 
becomes  the  primary  key,  and  that  primary  key  becomes  a  foreign  key  on  the  many  side 
of  1:M  relationships. 

2.  Normalization 

Relations  are  often  defined  in  a  form  that  suffers  from  problems  in  terms  of 
integrity  and  maintainability.  Updates  to  a  database  may  result  in  the  elimination  of 
useful  data  as  an  unwanted  side  effect.  Also,  when  the  data  is  defined  as  a  single  large 
table,  updates  can  result  in  large  amounts  of  redundant  data.  Classes  of  relational 
database  forms,  called  normal  forms,  are  defined  to  avoid  these  problems  and  maintain 
high  integrity  and  maintainability.  The  process  of  creating  the  appropriate  normal  forms 
is  called  normalization.  (Teorey,  1990,  p.  91) 
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Normalization  is  a  process  of  assigning  attributes  to  the  appropriate  entities. 
It  is  a  bottom  up  approach  to  data  modeling.  The  principles  of  normalization  dictate  that 
data  items  belong  together  in  a  logical  group,  and  these  groups  can  be  identified  by  their 
own  unique  identifier  or  key.  Tlhe  data  in  each  group  should  describe  one,  and  only  one 
thing.  Normalization  for  the  relational  model  usually  requires  normalizing  relations  to 
Boyce-Codd  Form,  or  the  equivalent  as  defined  below. 

Recalling  the  definitions  of  a  relational  data  model,  all  relations  are  said  to  be 
in  first  normal  form  (INF)  if  they  have  non-repeating  groups  within  a  tuple.  Consider 
the  relation; 

ROUTE  (Point  Number.  Location) 

where  Location  represents  the  location  of  a  point.  This  is  a  repeating  group  for  multiple 
missions  because  different  locations  may  be  assigned  the  same  point  number  for  separate 
missions.  To  fix  this,  the  relation  would  become; 

ROUTE  (Point  Number.  Mission  Number.  Location) 
where  each  location  would  have  a  separate  tuple. 

A  relation  is  in  second  normal  form  (2NF)  if  it  is  in  INF  and  all  non-key 
attributes  are  dependent  on  the  primary  key.  An  example  would  be  the  Route  relation 
used  earlier; 

ROUTE  (Point  Number.  Mission  Number.  Location,  Mission  Type)  where 
Mission  Number  -->  Mission  Type 

The  non-key  attribute  is  dependent  on  part  of  the  primary  key.  To  fix  this  the  relation 
is  decomposed  into  the  following  two  relations; 
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ROUTE  (Point  Number.  Mission  Number.  Location) 


MISSION  (Mission  Number.  Mission  Type) 

A  relation  is  in  third  nonnal  form  (3NF)  if  the  above  exists  and  there  is  no 
non-key  attribute  determined  by  anything  but  the  key  (transitive  dependency).  A  relation 
in  violation  of  third  normal  form  would  be: 

ROUTE  (Point  Number.  Mission  Number.  Location,  Location  Comments) 
where  Point  Number,  Mission  Number  — >  Location 
Location  — >  Location  Comment 

This  is  in  violation  because  Location,  a  non-key  attribute  determines  Location  Comment, 
another  non-key  attribute.  This  is  fixed  by  decon^osing  the  relation  into  two  relations: 
ROUTE  (Point  Number.  Mission  Number.  Location) 

LOCATION  (Location,  Location  Comments) 

Finally,  a  relation  is  in  Boyce-Codd  Normal  Form  (BCNF)  if  every 
determinant  is  a  candidate  key,  or  no  anomalies  regarding  functional  dependencies  exist. 
BCNF  deals  with  relations  with  overlapping  keys.  An  example  of  a  relation  with 
overlapping  keys  is: 

ROUTE  (Point  Number.  Mission  Number.  Location.  Point  Name) 
where  Point  Number,  Mission  Number  — >  Point  Name 
Point  Number,  Location  — >  Point  Name 

These  are  overlapping  keys  because  both  keys  contain  Point  Number.  To  fix  this 
problem,  the  relation  is  decomposed  into  two  relations: 

ROUTE  (Point  Number.  Mission  Number.  Location) 
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POINT  (Point  Number.  Point  Name) 

A  decomposition  is  said  to  be  lossless  if  it  preserves  the  functional 
dependencies  of  the  original  relation.  For  example  if  the  two  decomposed  relations  above 
are  joined,  the  resulting  relation  will  be  equal  to  the  original  relation. 

The  bottom-up,  or  normalization  approach  in  developing  a  logical  database 
design  will  result  in  the  relations  being  normalized  to  the  degree  required,  usually,  a 
collection  of  tables  in  BCNF.  The  resulting  processable  schema  allows  the  DBMS  to 
physically  manage  the  database. 

O.  SCENARIO 

To  model  the  user  defined  requirements,  a  simple  scenario  will  be  described  based 
on  current  operations  in  the  DASC.  The  DASC  wUl  be  treated  as  a  "black  box"  i.e., 
ignoring  its  internal  functions.  Likewise,  external  agencies  will  be  ignored.  The  E-R 
model  is  concerned  only  with  the  information  requirements  of  the  DASC,  not  the  means 
by  which  information  was  transmitted  or  received,  or  its  origin  or  destination. 

The  scenario  is  as  follows: 

1.  The  DASC  receives  the  ATO  and  manipulates  it  for  display  on  the 
appropriate  log  (FRAG). 

2.  The  DASC  receives  JTAR  26-1  and  processes  it,  assigning  a  mission  to 
execute  it. 

3.  The  DASC  transmits  mission  data  to  the  requestor  and  requests  launch  of 
the  assigned  mission. 
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4.  The  aircraft  reports  to  the  DASC,  the  DASC  briefs  the  A/C  using  the  9- 
line  brief  format,  and  turns  the  A/C  over  to  the  terminal  controller  at  the 
appropriate  control  point. 

5.  The  DASC  requests  mission  status  on  a  rotary  wing  mission. 

6.  The  A/C  executing  JTAR  26-1  checks  out  with  the  DASC,  mission 
complete,  with  a  BDA. 

7.  The  DASC  receives  a  change  to  a  preplanned  mission. 

8.  At  the  end  of  the  day,  the  DASC  transmits  an  operational  summary 
(OPSUM)  report. 

E.  DASC  DATABASE  DESIGN 

Relational  database  application  capabilities  will  be  demonstrated  by  extracting 
information  from  the  current  databases  used  in  the  DASC.  This  involves  combining  the 
automated  files  (MTS  ATO),  non-automated  data  (immediate  requests,  RIO  logs,  BDAs, 
operational  summary),  and  user  requirements  discussed  in  Chapter  HI. 

This  information  provides  the  basis  for  determining  the  entities,  attributes,  and 
relationships  for  the  E-R  diagram.  The  abbreviations  and  field  structures  of  the  identifiers 
duplicated  the  existing  MTF  and  report  formats  where  applicable.  The  following  entities 
were  identified  to  pertain  to  the  DASC  ATO  application: 

•  AIR  TASKING  ORDER  -  defines  time  period  and  type  of  ATO 

•  BATTLE  DAMAGE  ASSESSMENT  -  defines  mission  results  of  a  particular  target 

•  CONTROL  AGENCY  -  defines  characteristics  of  a  particular  control  agency 

•  IMMEDIATE  REQUESTS  -  defines  unit  supported  for  an  immediate  air  support 
request 
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•  MISSION  (ATO  MISSION)  -  defines  basic  characteristics  of  the  particular  mission 
to  include  aircraft  data 

•  MISSION  LOCATION  -  defines  mission  location 

•  RECEIVING  AIRCRAFT  -  defines  mission  data  for  aircraft  requiring  refueling 

•  RECONNAISSANCE  -  defines  reconnaissance  data 

•  RECON  TARGET  -  defines  reconnaissance  target  data 

•  RIO  LOGS  -  defines  actual  mission  data 

•  ROUTE  -  defines  mission  route  information 

•  TARGET  LOCATION  -  defines  mission  target  data 

The  relationships  defined  between  entities  depicted  in  Figure  8  include; 

•  ASSESSES  -  BDA  may  be  reported  on  a  TARGET  LOCATION 

•  COMPRISES  -  ATO  is  comprised  of  various  MISSIONS 

•  CONTROLS  -  MISSION  is  controlled  by  various  CONTROL  AGENCY(ies) 

•  INTEREST  IN  -  RECONNAISSANCE  mission  executes  various  RECON 
TARGETS 

•  MAY  DESIGNATE  -  MISSIONS  may  follow  certain  ROUTES 

•  REFUELS  -  MISSION  LOCATION  may  refuel  RECEIVING  AIRCRAFT 
-  REQUESTS  -  IMMEDIATE  REQUESTS  request  MISSION  to  perform 

•  UPDATES  -  RIO  LOGS  update  the  ATO  with  actual  mission  data 

Mapping  cardinality  between  each  entity  was  specified  to  complete  the  diagram. 
Appendix  D  lists  the  cardinality  rules  used  for  each  link. 

Figure  8  depicts  the  resulting  E-R  diagram  using  an  E-R  modeling  tool  called  E-R 
Designer  by  Peter  Chen  and  Associates.  Appendix  D  lists  and  explains  the  entities, 
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attributes,  relationships,  and  cardinality  rules  depicted  on  the  E-R  diagram. 

The  entities  BDA  and  Target  Location  linked  by  the  relationship  will  be 

used  as  an  example  of  how  to  read  the  diagram:  There  can  be  as  few  as  zero  or  as  many 
as  N  (many)  BDAs  assessing  each  Target  Location;  and  there  can  be  one  and  only  one 
Target  Location  assessed  in  each  BDA.  The  term  TSA’  refers  to  a  generalization 
occurrence  on  the  entity  ATO  Mission.  ATO  Mission  must  have  one  of  the  entities; 
Target  Location,  Mission  Location  or  Reconnaissance,  as  a  member. 

The  E-R  model  was  then  loaded  into  the  Normalizer  tool  of  E-R  Designer  to 
validate  the  schema.  The  initial  schema  generated  by  the  E-R  Designer  tool  is  shown  in 
Appendix  E.  Functional  dependencies  (FD)  were  defined  in  each  relation.  The 
normalizer  tool  normalized  the  relations  to  the  BCNF  and  decomposed  the  relations  into 
FD-pre “serving  and  lossless-join  3NF  relations.  It  also  ensured  that  complex  relations 
were  broken  down  into  simpler  ones  in  which  related  data  items  were  grouped  and 
duplication  minimized.  The  user  interaction  log  for  defining  the  functional  dependencies 
is  listed  in  Appendix  F.  The  resulting  schema  from  the  Normalizer  tool  is  displayed  in 
Appendix  G. 

F.  IMPLEMENTING  THE  DASC  SCHEMA  ON  A  RELATIONAL  DBMS 

The  relational  schema  developed  in  the  previous  section  is  not  linked  to  any  specific 
DBMS.  No  database  package  meets  all  the  features  and  qualifications  of  a  "fully 
relational"  database;  however,  many  relational  databases  exist  that  can  use  the  schema 
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generated.  To  demonstrate  the  potential  of  a  relational  database,  dBASE  IV  is  used  as 
a  prototype  implementation  of  the  DASC  application. 

A  DBMS  is  a  program,  or  set  of  programs,  that  processes  the  database.  The  DBMS 
allows  the  user  to  create,  maintain,  and  access  a  database.  The  DBMS  allows  the 
program  to  be  separate  from  the  application.  The  application  can  be  thought  of  as  a 
collection  of  menus,  forms,  reports,  and  programs  that  satisfies  the  needs  of  a  user  or 
group  of  users.  The  DBMS  is  a  set  of  programs  or  tools  which  allows  developers  to 
design  and  implement  a  system  which  users  can  access.  (Kroenke,  1987.  p.  62)  The 
features  and  functions  of  a  DBMS  include; 

•  Change  the  data  as  the  real  world  changes 

•  Support  a  data  structure  that  corresponds  to  the  real  world 

•  Protect  the  data  from  corruption  from  authorized  users 

-  Protect  the  data  from  unauthorized  users 

•  Support  access  to  data  by  multiple  users  simultaneously 

•  Recover  from  software  and  hardware  failures 

'  Get  information  out  of  the  database  easily 

•  Improve  productivity  of  the  development  programmers 

-  Reasonable  performance 

A  database  was  created  using  the  normalized  relational  schema  field  format 
developed  by  E-R  Designer.  A  simulated  ATO  was  loaded  into  the  database.  Reports 
were  generated  linking  tables  to  get  the  desired  outputs.  Ad  hoc  queries  were  conducted 
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to  determine  the  application  capabilities.  Sample  reports  and  queries  are  listed  in 
Appendix  H. 

Database  generation  creates  an  actual  physical  structure  which  is  generated  from  the 
conceptual  schema.  The  DASC  application  schema  created  by  E-R  Designer  and  listed 
in  Appendix  G  determined: 

•  database  names 

-  field  names 

•  field  types 

•  field  length 

The  data  files  created  above  were  used  to  define  the  database  structure  in  dBASE 
IV.  dBASE  IV  uses  a  main  menu  called  the  Control  Center  to  access  and  store  files. 
dBASE  rv  achieves  the  functions  of  data  management  (creation,  interrogation,  updating, 
administration)  through  the  Control  Center.  For  example,  the  relation  Ait  Tasking  Order 
was  used  to  create  the  database  file  ATO  in  the  Data  Panel.  Field  names  were  derived 
from  the  attributes  ATO  Start,  ATO  Stop,  and  Air  Tasking  Code  using  the  attribute  type 
(character  or  numeric)  and  length  as  shown  in  Appendix  G. 

Unless  otherwise  specified,  dBASE  IV  stores  records  in  the  order  in  which  they  are 
entered.  dBASE  FV  can  be  manipulated  to  store  and  retrieve  data  in  a  sorted  order  by 
physically  rearranging  the  records.  Another  way  to  sort,  or  retrieve,  data  is  by  creating 
an  index  field  on  a  field  value.  Indexes  allow  data  to  be  retrieved  "directly"  rather  than 
by  doing  a  sequential  search,  thus  indexing  makes  some  retrievals  more  efficient.  For 
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example,  since  the  DASC  ATO  application  will  require  information  on  particular  mission 
numbers,  the  Mission  Number  field  was  indexed  when  delineated  in  a  database  (relation). 

Once  the  database  structures  were  created,  data  was  loaded  into  the  appropriate 
databases.  An  ATO  was  developed  consisting  of  seven  missions.  Manual  insertion  of 
data  was  done  ensuring  all  tables  contained  some  data.  The  actual  DASC  application  wUl 
require  a  compiling  program  and  parser  to  automatically  upload  MTS  data  to  the  DASC 
application. 

The  next  step  was  to  create  database  queries  and  views.  A  query  is  the  retrieval  of 
a  specific  table,  possibly  requiring  the  join  of  two  or  more  tables,  to  meet  a  stated 
condition.  Queries  may  require  that  data  be  drawn  from  multiple  tables.  dBASE  IV  uses 
views  to  help  with  query  operations.  In  general,  a  view  is  a  virtual  table  which  is  a 
subset  of  one  or  more  existing  tables  in  the  database.  In  dBASE  IV,  it’s  acmally  stored 
physically  but  this  is  not  how  all  DBMSs  do  views.  For  example,  a  mission  status  may 
be  requested  on  a  troop  lift  from  the  DASC.  The  DASC  would  use  the  DASC  application 
to  find  this  information  by  creating  a  view  linking  the  attributes  of  A/C  Status  database 
with  the  A/C  Weapons  database.  A  query  is  made  on  this  view  listing  all  records  whose 
A/C  Type  field  type  is  "CH-46".  This  query  would  create  a  view  of  the  mission  data  of 
mission  "30H0002".  These  queries  can  be  permanently  stored  in  the  Queries  panel  of  the 
control  center  in  dBASE  IV. 

Forms  files  display  customized  screens.  This  can  be  used  for  entering,  updating  and 
displaying  data  on  a  particular  form.  The  custom  form  can  be  created  using  the  tools  in 
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dBASE  IV.  An  example  is  the  Battle  Damage  Assessment  form  contained  in  Appendix 
H.  Forms  may  also  be  created  using  the  special  views  created  in  the  queries  panel. 

Reports  can  be  generated  in  dBASE  FV  from  one  or  more  tables  using  the  above 
procedures.  The  reports  can  be  printed  or  displayed  on  screen.  Appendix  H  contains  a 
sample  Report-In/Out  Log  and  Immediate  Air  Suppon  Summary  Report. 

Design  and  implementation  of  the  DASC  schema  as  described  above  is  the 
responsibility  of  the  Database  Administrator  (DBA).  The  DBA  must  ensure  that  the 
integrity  of  the  underlying  DASC  database  is  maintained  at  all  times.  This  entails  a 
number  of  critical  functions  as  described  next. 


G.  DATABASE  ADMINISTRATION  FOR  THE  DASC  DATABASE 

Database  Administration  is  a  technical  function  that  is  responsible  for  physical 
database  design  and  for  dealing  with  technical  issues  such  as  security  enforcement, 
database  performance,  and  backup  and  recovery.  (Hoffer,  1991,  p.  339)  The  Database 
Administrator  for  the  DASC  database  will  need  to  be  involved  with  the  following: 

•  referential  integrity 

•  concurrency  control 

•  backup  and  recovery 

•  database  security 

•  handling  missing  data 

•  training 
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1.  Referential  Integrity 

Referential  integrity  is  concerned  with  the  validity  of  references  by  one  object 
in  a  database  to  some  other  object(s)  in  the  database.  Rows  in  one  relation  may  refer  to 
a  row  in  another  relation,  and  problems  can  occur  when  inserting/deleting  data.  A 
referential  integrity  constraint  requires  that  for  each  row  of  one  table,  the  "referencing 
table",  the  value  of  the  foreign  key  value  must  be  the  same  as  the  value  of  the 
corresponding  primary  key  column  in  some  row  of  the  referenced  table  or  else  be  null. 
A  row  should  not  be  able  to  be  inserted  in  the  referencing  table  unless  it  exists  in  the 
referenced  table.  Additionally,  a  row  should  not  be  able  to  be  deleted  from  the  referenced 
table  if  there  is  a  matching  row  in  the  referencing  table.  For  example,  if  a  mission  is 
deleted  from  the  A/C  Status  relation,  then  the  deletion  should  either: 

1 .  be  deleted  in  every  relation  which  contains  the  same  mission, 

2.  be  disallowed,  or 

3.  nullify  the  mission  number  attribute  in  the  referencing  table(s). 

Referential  integrity  constraints  can  be  enforced  by  an  application  program  or 
by  a  DBMS  that  includes  facilities  for  enforcement.  dBASE  IV  does  not  provide 
referential  integrity  facilities. 

2.  Concurrency  Control 

Concurrency  in  a  database  environment  means  that  more  than  one  user  can 
access  and  manipulate  data  at  the  same  time.  Multiple  users  of  the  DASC  database  can 
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compromise  the  data  unless  there  is  concurrency  control.  An  example  would  be  where 
users  A  and  B  both  update  the  relation  Battle  Damage  Assessment.  User  A  updates  the 
field  BDA  Comment  and  saves  the  data,  while  user  B  updates  the  field  Unit  Supported 
and  saves  the  data  5  seconds  later.  The  information  updated  by  user  A  would  be  lost. 

Controlling  concurrent  access  may  be  done  by  locking  or  denying  access  to 
other  users  until  the  update  is  completed.  Locks  may  be  implemented  at  different  levels 
(database,  table,  block,  record,  field),  and  may  provide  shared  access  but  allow  only  one 
update  user.  DBMS  products  provide  different  locking  csqjabilities.  dBASE  IV  provides 
concurrency  control  by  locking  records  automatically  by  default,  or  by  locking  table 
access  through  the  protect  and  e.xdusive  use  commands  in  the  application  generator  tool. 

3,  Backup  and  Recovery 

Database  recovery  procedures  are  required  to  restore  a  database  quickly  after 
a  loss  or  damage.  The  DBMS  should  have  tools  to  recover  data  from  program  aborts, 
software  failures,  and  hardware  failures.  In  program  aborts,  the  DBMS  detects 
transactions  started  and  aborted  without  "commit",  then  effects  an  automatic  "rollback". 
When  a  system  "crashes"  or  loses  power,  the  DBMS  examines  the  transaction  log  once 
initiated  and  effects  a  "rollback"  for  all  incomplete  transactions.  The  database  must  be 
restored  from  a  backup  copy  for  hardware  failures,  and  the  DBMS  must  reproduce 
transactions  on  log  since  the  backup.  dBASE  IV,  for  example,  provides  automatic 
"rollback"  through  the  application  generator  tool.  dBASE  TV  also  has  the  capability  to 
log  terminal  activities  into  a  text  file  to  produce  and  an  audit  trail  of  database 
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transactions.  This  audit  trail,  however,  cannot  be  automatically  reapplied  to  restore  the 
database. 

4.  Database  Security 

Data  Security  protects  the  data  from  unauthorized  users.  The  first  level  of 
security  is  physical  security.  The  next  is  the  use  of  passwords  both  into  the  system  and 
into  the  programs.  The  DBA  can  create  views  for  different  classes  of  users  controlling 
the  type  of  access  (read,  write,  delete)  each  user  has  to  the  data. 

5.  Handling  Missing  Data 

Procedures  must  be  established  by  the  database  administrator  to  handle  missing 
information.  Data  that  is  missing,  lost,  or  incomplete  in  the  DASC  application  must  be 
dealt  with  in  the  design  phase. 

6.  Training 

The  DBA  interfaces  with  the  users  for  training  purposes,  and  to  determine 
ongoing  system  requirements.  DBMS  software  is  complex  and  consumes  resources. 
Performance  is  measured  in  time  required  to  support  a  function,  number  of  users 
supported,  and  number  of  transactions  per  second.  There  is  a  trade-off  between 
performance  vs.  features,  performance  vs.  flexibility,  and  performance  vs.  portability. 
Reasonable  performance  will  depend  on  the  balance  of  these  trade-offs.  (Hoffer,  1991, 
p.  363-384) 
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H.  SUMMARY 


This  chapter  discussed  and  applied  the  relational  theory  for  data  modeling  to  the 
DASC  application  using  the  E-R  approach  and  normalization.  An  entity-relationship 
model  created  by  the  support  tool  E-R  Designer  was  combined  with  the  Normalizer 
support  tool  to  develop  a  relational  schema  for  the  DASC  application.  The  logical  data 
stmcture  was  translated  to  a  relational  schema,  and  implemented  on  a  microcomputer 
DBMS  called  dBASE  IV.  Although  further  work  is  needed  before  the  DASC  application 
can  be  fully  implemented  as  a  functional  prototype,  the  potential  for  this  approach  and 
resulting  application  was  demonstrated.  The  Database  Administrator  will  play  a  key  role 
in  developing  the  DASC  ATO  application.  A  DBMS  that  provides  interactive 
management  facilities  will  assist  the  DBA  in  his  responsibilities. 

The  final  chapter  summarizes  the  study’s  results,  and  suggests  areas  for  future 

study. 
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V.  CONCLUSIONS 


A.  CONCLUSIONS 

This  thesis  developed  a  logical  schema  for  a  centralized  relational  database,  given 
the  requirement  specifications  for  a  DASC  database  application.  The  thesis  illustrates  the 
steps  of  E-R  modeling,  normalization,  and  implementation  of  the  schema  using  a 
relational  DBMS.  Database  design  is  an  evolving  activity.  As  user  requirements  expand 
and  change,  the  conceptual  schema  and  database  structures  must  change  accordingly.  The 
methodology  used  in  the  original  design  is  important  since  it  may  be  reused  to  keep  the 
database  current  as  more  aspects  of  the  DASC  application  are  developed. 

The  E-R  approach  is  particularly  useful  in  the  early  stages  of  the  database  lifecycle, 
which  involves  requirements  analysis  and  logical  design.  When  requirements  are 
determined  from  end-user  interviews  and  modeled  in  terms  of  E-R  diagrams,  immediate 
feedback  can  be  obtained  concerning  the  validity  of  the  database.  Another  advantage  of 
the  E-R  approach  is  that  the  schema  is  independent  of  any  particular  DBMS  environment 
and  tiierefore  can  be  used  with  potentially  many  different  DBMS  platforms. 

Once  a  logical  data  structure  has  been  generated,  it  is  a  straightforward  process  to 
implement  the  schema  in  a  specific  environment  as  we  have  shown  with  dBASE  IV.  The 
relational  DBMS  manages  ad  hoc  queries  and  new  applications  that  would  be  more  time 
consuming  to  implement  with  other  models. 


56 


Relational  databases  are  easy  to  design,  maintain,  and  use.  They  enforce  data 
independence  and  encourage  data  sharing.  They  readily  support  application  development, 
prototyping,  and  distributed  data  applications.  Relational  architecture  will  support  many 
applications  and  is  recommended  for  adoption  for  implementation  of  the  DASC 
application. 


B.  FURTHER  RESEARCH 

This  thesis  represents  only  an  initial  study  into  the  potential  of  implementing  a 
relational  database  application  in  the  DASC.  The  study  examined  a  passive  DBMS  where 
queries  and  transactions  occurred  only  when  explicitly  requested  by  the  user  or 
application  program.  Future  study  is  suggested  in; 

•  design  of  an  active  database  management  system  aimed  at  meeting  the  needs  of 
applications  requiring  time-constrained  data  management  and  processing.  A  High 
Performance  Active  (HIPAC)  DBMS  automatically  monitors  events,  evaluates 
conditions  defined  over  the  state  of  the  database  when  appropriate  events  occur, 
and,  based  on  the  result  of  conditions  evaluation,  invokes  actions  associated  with 
the  event-condition  pair. 

•  evaluation  of  implementing  the  database  design  in  SYBASE,  the  Marine  Corps’ 
chosen  standard  for  relational  DBMSs. 

•  evaluation  of  the  alternative  file  indexing  stmctures  of  the  DASC  application.  This 
system  performance  evaluation  should  determine  the  stmcture  with  the  best 
performance  while  minimizing  the  volume  of  the  database. 

•  define  the  structure  and  content  of  a  database  that  would  support  the  entire  Marine 
Air  Command  and  Control  System  and  Marine  Tactical  Command  and  Control 
System.  Standardization  of  data  elements  used  within  the  system  should  be 
addressed.  Considerations  should  be  given  to  implementing  the  design  in  a 
distributed  database  environment. 
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•  development  of  an  expert  system  for  assignment  of  missions  to  immediate  air 
requests  that  interacts  with  the  DASC  application.  The  expert  system  could  be 
based  upon  standard  operating  procedures  to  assist  decision  makers  in  the  DASC. 

•  determine  the  communication  equipment  requirements  to  include  parser  and 
compiJing  requirements  for  the  transmission,  receipt,  and  storage  of  the  ATO.  This 
should  include  security  and  integrity  checking  in  the  transmission  specifications. 
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APPENDIX  A:  GLOSSARY 


Anomaly  -  An  undesirable  consequence  of  a  database  modification. 

Application  -  A  collection  of  menus,  reports,  forms,  and  programs  that  addresses  the 
needs  of  the  users. 

Attribute  -  A  data  element  that  describes  an  entity.  A  column  of  field  in  a  relation. 

Candidate  Key  -  An  attribute  or  attribute  group  that  could  be  used  as  a  key  in  a  relation. 

Command  and  Control  Facility  (C2FAC)  -  An  organization  element  that  needs  to 
communicate  with  another  to  perform  its  tasks. 

Command  and  Control  (C2)  System  -  The  facilities,  equipment,  communications, 
procedures,  and  personnel  essential  to  a  commander  for  planning,  directing,  and 
controlling  operations  of  assigned  forces  pursuant  to  the  missions  assigned. 

Data  -  A  fact  or  condition  represented  in  a  form  that  is  usable  by  an  Automated  Data 
System  including  its  operators. 

Data  Item  -  The  smallest  unit  of  named  data  that  has  meaning  in  the  real  world. 

Data  Dictionary  -  A  user-accessible  catalog  of  data  about  a  database. 

Data  Element  -  Used  synonymously  with  data  item. 

Data  Field  Identifier  (DFI)  -  The  DFl  provides  the  identification  for  the  class  of  data 
relating  to  a  message  field  in  the  MTS  message  standard.  The  DFI  contains  a  unique 
number,  name,  and  definition.  The  DFI  is  a  generic  definition  of  the  concept  represented 
by  all  associated  DUIs.  All  DFIs  most  have  at  least  one  associated  DUI. 

Data  Model  -  A  language  describing  the  structure  and  processing  of  a  database. 

Data  Use  Identifier  (DUI)  -  The  DUI  further  identifies  the  functional  or  categorical 
context  in  which  the  DFI  is  used.  The  DUI  contains  a  unique  name  among  all  DUIs  and 
a  unique  number  among  the  DUIs  within  the  DFI.  All  DUIs  have  at  least  one  Data  Item 
(DI)  or  field  or  attribute. 
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Database  -  An  organized  and  integrated  collection  of  stored  operational  data  used  by  an 
Automated  Data  System. 

Database  Administrator  -  The  person  or  group  responsible  for  the  design,  creation, 
maintenance,  and  control  of  the  database. 

Database  Management  System  -  A  software  function  providing  data  handling  services 
to  operators  (end  users),  application  programmers,  and  Database  Administrators. 

Entity  -  A  real  world  object  that  is  important  to  the  system  application. 

Entity  Instance  -  An  occurrence  of  an  entity. 

Entity-Relationship  Diagram  -  A  diagram  used  in  database  design  that  illustrates  entities 
and  the  associations  among  them. 

File  -  The  collection  of  records  of  a  single  type. 

Foreign  Key  -  An  attribute  that  has  a  key  of  a  different  relation. 

Functional  Dependency  -  Relationship  between  X  and  Y  such  that,  given  a  value  of  X, 
one  can  determine  the  value  of  Y.  Written  as  X  ->  Y. 

Hierarchical  Data  Model  -  A  data  model  that  such  that  each  record  has  exactly  one 
parent,  except  the  root,  which  has  no  parent. 

Identifier  -  The  attribute(s)  and/or  relationship(s)  that  uniquely  identify  a  particular  entity. 

Interoperability  -  The  ability  of  systems,  units,  or  forces  to  provide  services  to,  and 
accept  services  from  other  systems,  units,  or  forces,  and  to  use  the  services  exchanged  to 
enable  them  to  operate  effectively  together. 

Intraoperability  -  Interoperability  among  the  Marine  Corps  systems. 

Key  -  A  group  of  one  or  more  attributes  that  uniquely  identifies  a  row  (tuple,  record) 

Local  Area  Network  -  A  collection  of  geogreqjhically  close  microcomputers  that 
communicate. 

Meta-data  -  Data  about  the  structure  of  a  database  that  is  stored  in  the  data  dictionary. 

Network  Data  Model  -  A  data  model  in  which  all  relationships  are  one-to-many  and  a 
child  can  have  multiple  parents  as  long  as  they  are  different  record  types. 
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Primary  Key  -  An  attribute  or  attribute  group  chosen  as  the  key  of  a  relation. 

Protocol  -  Communication  protocols  are  processes  or  sets  of  rules  controlling  the 
interchange  of  information. 

Record  -  A  group  of  related  data  items  treated  as  a  unit. 

Record  Type  -  Defines  the  structure  of  a  record  by  identifying  the  names  of  the  data 
elements  present. 

Record  Occurrence  -  One  particular  instance  of  a  record  type  with  values  assigned  to 
the  data  elements. 

Relation  -  A  two-dimensional  table  containing  single  valued  entries  and  no  duplicate 
rows. 

Relational  Database  -  A  database  structured  in  accordance  with  the  relational  data  model. 

Relational  Data  Model  -  A  data  model  in  which  data  is  stored  in  tables,  and  association 
between  tables  are  represented  within  the  table  data. 

Relationship  -  An  association  between  two  entities. 

Schema  -  A  logical  view  of  a  database. 

Transitive  Dependency  -  A  relationship  between  attributes  X,  Y,  and  Z  such  that,  if  Y 
is  determined  by  X,  and  Z  is  determined  by  Y,  then  Z  is  determine  by  X.  Written  as  if 
X  ->  Y  and  Y  ->  Z,  then  X  ->  Z. 

Tuple  -  A  row  or  record  in  a  relation. 
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APPENDIX  B:  MILITARY  ACRONYMS 


AAW  -  Antiair  Warfare 

ACCS  -  Army  Command  and  Control  System 

ACE  -  Aviation  Combat  Element 

ASOC  -  Air  Support  Operations  Center 

ASR  -  Assault  Support  Request 

ASRT  -  Air  Support  Radar  Team 

ATO  -  Air  Tasking  Order 

BDA  -  Bomb  Damage  Assessment 

CAS  -  Close  Air  Support 

COC  -  Combat  Operations  Center 

CP  -  Command  Post  or  Control  Point 

CRLCMP  -  Computer  Resources  Life  Cycle  Management  Plan 

C2  -  Command  and  Control 

C2FAC  -  Command  and  Control  Facility 

C3I  -  Command,  Control,  Communication  and  Intelligence 

DASC  -  Direct  Air  Support  Center 

DCT  -  Digital  Communications  Terminal 

DPI  -  Data  Field  Identifier 

DI  -  Data  Item 

DUI  -  Data  Use  Identifier 

EMP  -  Electro-magnetic  Pulse 
EW/C  -  Early  Waming/Control 

FAC  -  Forward  Air  Controller 

FAC(A)  -  Forward  Air  Controller  (Airborne) 

FMFM  -  Fleet  Marine  Field  Manual 
FRAGO  -  Fragmentation  Operation  Order 
FSCC  -  Fire  Support  Coordination  Center 
FBC  -  Future  Battle  CeU 

GCE  -  Ground  Combat  Element 

HC(A)  -  Helicopter  Coordinator  (Airborne) 
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IDASC  -  Improved  DASC  (Facility) 

ISEA  -  In-service  Engineering  Agent 

JTAR  -  Joint  Tactical  Air  Request 

LAAD  -  Low  Altitude  Air  Defense 
LAAM  -  Light  Antiaircraft  Missile 

MACCS  -  Maine  Air  Command  and  Control  System 

MACG  -  Marine  Air  Control  Group 

MAGTF  -  Marine  Air-Ground  Task  Force 

MATCS  -  Marine  Air  Traffic  Control  Squadron 

MCASS  -  MTACCS  Common  Application  Support  Software 

MCHS  -  MTACCS  Common  Hardware  Suite 

MCTSSA  -  Marine  Corps  Tactical  System  Support  Activity 

MMI  -  Man-machine  Interface 

MTACCS  -  Marine  Corps  Tactical  Command  and  Control  System 
MTF  -  Message  Text  Format  (also  USMTF) 

MTS  -  Marine  Tactical  Systems 

NAVELEXCEN  -  Naval  Electronics  Systems  Engineering  Center 

NDI  -  Non-developmental  Item 

NTACS  -  Naval  Tactical  Air  Control  System 

ORD  -  Operational  Requirements  Document 

PLRS  -  Position,  Location,  and  Reporting  System 
P3I  -  Pre-planned  Product  Improvement 

RAC  -  Refueling  Area  Coordinator 
RIO  -  Report  in/out 
ROC  -  Required  Operational  Capability 
RPV  -  Remotely  Piloted  Vehicle 

SAAWC  -  Sector  Antiair  Warfare  Coordinator 
SAD  -  Senior  Air  Director 

TAC  -  Tactical  Air  Commander 

TAC(A)  -  Tactical  Air  Coordinator  (Airborne) 

TACC  -  Tactical  Air  Command  Center  (USMC) 

TACP  -  Tactical  Air  Control  Party 

TACS  -  Tactical  Air  Control  System  (US  Air  Force) 
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TAOC  -  Tactical  Air  Operations  Center 
TAR  -  Tactical  Air  Request 
TCO  -  Tactical  Combat  Operations 
TDS  -  Tactical  Data  Systems 
TIDP  -  Tactical  Interface  Design  Plan 

USMC  -  United  States  Marine  Corps 


64 


APPENDIX  C:  DASC  INFORMATION  REQUIREMENTS 
This  appendix  exhibits  current  DASC  information  requirements  pertaining  to  the 
ATO  database  application.  The  messages,  forms,  and  reports  included  are: 

•  the  message  text  format  Air  Tasking  Order 

•  the  Joint  Tactical  Airstrike  Request 

•  the  Report-In/Out  Log 

•  the  Operational  Summary  Report 
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AIR  TASKING  ORDER 


1.  General 

The  Air  Tasking  OrderA^i^onfirmation  message  is  computer  readable  and  includes 
information  based  on  the  users  needs.  The  message  can  include  the  following  groups  of 
information.  If  the  group  (set)  is  used  the  format  is  as  follows: 

SET  NAME/FIELD  l/RELD  2/.../FIELD  N// 

•  Mandantory  sets  and  fields  are  underlined.  A  field  is  mandandory  only  if  that  set 
is  mandantory. 

•  Vetical  lines  with  arrows  show  repeatable  sets  and  nested  segments. 

-  Capital  letters  means  enter  as  is. 

2.  Message  Map 


EXER/exercise  name/additional  identifier// 

OPER/oneration  name/plan  orginator  and  number/option  name/second  option  name// 

MSlD/ATOCONF/oreinator/message  serial  number/month/qualifier/quailfier  serial 
number// 

REF/serial  letter/(usmtf  message  short  title)  or  (type  of  reference)/orginator/date- 
time  groupAmsg  ser  number)  or  (doc  ser  number)/special  notation/(sic)  or  (filing 
number)// 

AMPN/free  text  to  explain  preceeding  reference  set// 

NARR/free  text  to  explain  preceeding  reference  set// 

CANX/serial  letter/(usmtf  message  short  title)  or  (type  of  reference  )/orginator/date- 
time  groupAmsg  ser  number)  or  (doc  ser  numbcr)/special  notation/(sic)  or  (filing 
number)// 

PERlD/time  from/TO:  time  to/ASOF:  as  of  time// 

AlRTASK/air  tasking/air  tasking  comments// 

TASKUNTT/tasked  unit  designator/ICAO  location/comments// 
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MSNDATA/mission  number/package  identification/aircraft  call  signAiumber  and 
type  of  aircraft/mission  type/alert  status/primarv  configuration  code/secondarv 
configuration  code/iff-sif  code  and  mode// 

MSNLOC/mission  start  dav-time/mission  stop  dav-time/mission  location 
name/(altitude)  or  (flight  level )/air  support  request  number/area  coordinates// 

TGTLOC/dav-time  on  target/dav-time  off  target/target  identifierAarget  tvpe/desired 
mean  point  of  impact/air  support  request  number/target  comments// 

RECDATA/request  number/mission  priority/dav-time  on  target/latest  time 
information  of  yalue/reconnaissance  mission  type/coyerage  type/imagery 
type/imagery  code/coverage:mode/TGTCOD:  reconnaissance  target  code/print 
scale/delivery  address// 

TRCPLOT/location  of  initial  point/trace  point  location// 

CONTROL/type  of  control/callsignAprimary  frequency)  or  (primary  frequency 
designator )/( secondary  frequency)  or  secondary  frquency  designator )/report-in 
point/control  comments// 

FACINFO/callsign/tprimary  frequency)  or  (primary  frequency 
designator)/! secondary  frequency)  or  secondary  frquency  designator)/report-in 
point/support  unit  identity/control  comments// 

ELECMBT/aircraft  ca^sign^riority /mission  location/! altitude)  or  (flight  level)/time 
on  station/time  off  station/primary  (frequency)  or  frequency  designator/secondary 
(frequency)  or  frequency  designator// 

REFUELAanker  call  sign/tanker  mission  number/air  refueling  control  point/! altitude) 
or  !flight  level)/air  refueling  control  time/total  offload  of  fuel/primary  Ifreauency) 
or  frequency  designator/secondary  (frequency)  or  frequency  designator// 

TREFUEL/mission  number/aircraft  call  sign/number  and  type  aircrafi/total  offload 
of  fuel/air  refueling  control  time/tanker  assignment/refueling  fuel  type/recieyer 
comments/ 

AKNLDG/acknowledgement  instructions// 


DECL/downgrading  instructions// 


JOINT  TACTICAL  AIRSTRIKE  REQUEST 
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NUMBER  MISSIONS  SCHEDULED 

NUMBER  UNSCHEDULED  MISSIONS  FLOWN 

NUMBER  OF  MISSIONS  CANX 

TOTAL  NUMBER  MISSIONS  FLOWN 

TOTAL  NUMBER  OF  A/C  FLOWN 

NUMBER  MISSIONS  RIO' ED  IN 

P 

C 

B 

c 

p 

fl 

c 

p 

B' 

NUMBER  OF  MISSIONS  RIO' ED  OUT 

REMARKS : 


HELO 

DAILY  MONTHLY  TOTAL 

NUMBER  MISSIONS  SCHEDULED 

NUMBER  UNSCHEDULED  MISSIONS  FLOWN 

NUMBER  OF  MISSIONS  CANX 

TOTAL  NUMBER  MISSIONS  FLOWN 

TOTAL  NUMBER  OF  A/C  FLOWN 

NUMBER  MISSIONS  RIO' ED  IN 

P 

C 

B 

c 

p 

B 

c 

p 

B 

NUMBER  OF  MISSIONS  RIO' ED  OUT 

remarks : 
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OPSOM  (cont) 


MEDEVAC 

DAILY 

MONTHLY 

TOTAL 

RC 

VD 

CA 

NX 

CO 

MP 

RC 

VD 

CA 

NX 

CO 

MP 

RC 

VD 

CA 

NX 

C 

O 

M 

P 

ACTUAL 

SIMULATED 

REMARKS : 


JTAR 

DAILY 

MONTHLY 

TOTAL 

RC 

VD 

CA 

NX 

CO 

MP 

RC 

VD 

CA 

NX 

CO 

MP 

RC 

VD 

CA 

NX 

C 

O 

M 

P 

ACTUAL 

SIMULATED 

REMARKS : 


ASR 

DAILY 

MONTHLY 

TOTAL 

RC 

VD 

CA 

NX 

CO 

MP 

RC 

VD 

CA 

NX 

CO 

MP 

RC 

VD 

CA 

NX 

C 

O 

M 

P 

ACTUAL 

SIMULATED 

REMARKS : 


DAILY 

MONTHLY 

TOTAL 

TOTAL  OPERATIONAL  HOURS 

REMARKS : 
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APPENDIX  D:  ENTITV -RELATIONSHIP  SPECIFICATIONS 
This  appendix  lists  and  explains  the  information  depicted  on  the  Entity-Relationship 
diagram,  Figure  8.  It  includes; 

•  attribute  names,  abbreviations,  formats,  and  keys 

•  entities  and  relationship  attribute  listing 

•  cardinality  connections  and  rules 
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ENTITY-RELATIONSfflP  ATTRIBUTES 


Attribute  Name 

Abbreviation 

Format 

M3L 

Abbrev 

A/C_CALLSIGN 

C/S 

C,  12 

Y 

ATO  MSN 

Y 

REFULEE 

Comm:  A/C  callsign 

ACTUAL_TIME_OF_ARRIVAL  ATA 

N,  4 

N 

RIO_LOGS 

Comm:  Actual  time  A/C  reported 

in  with 

DASC 

ACTUAL_TIME_OF_RETURN  ATR 

N,  4 

N 

RIO_LOGS 

Comm:  Actual  time  A/C  reported 

out  with 

DASC 

AIRCRAFT_TYPE 

TYPE 

C,  6 

N 

ATO  MSN 

N 

REFULEE 

Comm:  Aircraft/helicopter  type /model /category 

(entry 

list  513) 

AIR_TASKING_CODE 

ATO  CODE 

C,  43 

Y 

ATO 

Comm:  Code  for  air 

tasking  type 

(entry 

list  2005) 

ALERT_STATUS 

ALR 

C,  3 

N 

ATO_MSN 

Comm:  Alert  status 

code  (Annex 

33  CH  3/USMTF) 

ALTITUDE 

ALT 

C,5 

N 

MSNLOC 

Comm:  A/C  altitude 

(Annex  2  CH 

3/USMTF) 

AMOUNT_OF  FUEL 

LBSFUEL 

N,  4 

N 

REFULEE 

Comm:  Amount  of  fuel  allowed  per  aircraft  in  hundreds  of  lbs 


ARRIVAL  TIME 

ATIME 

C,7 

N 

ROUTE 

Comm:  Arrival  time  (Annex  2  CH  3/USMTF) 

ATO_START 

ATO  START 

C,7 

Y 

ATO 

Comm: Day,  hour,  minute. 

time  zone  of  ATO  Start 

ATO_STOP 

ATO  STOP 

C,7 

Y 

ATO 

Comm:  Day,  hour,  minute. 

time  zone  of  ATO  stop 

BDA  COMMENT 

BDACMNT 

C,  30 

N 

BDA 

Comm:  Description  of  results 

CALLSIGN 

CALLSIGN 

C,15 

Y 

CONTROL 

Comm:  Control  agency's  callsign 
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CONTROL_AGENCy 

CONT 

C,4 

N 

CONTROL 

Conun:  Code  for  the 

control  agency  type 

from  the  event  ! 

list 

CONTROL_POINT 

RIO  CP 

C,  20 

N 

CONTROL 

Conun:  Location  the 

A/C  is  to  check  in  with  the  control 

agency 

CONTROL  POINT  TYPE 

CPTYP 

C,  3 

N 

ROUTE 

Conun:  Code  for  the 

route  point  type  (Annex  2 

CH  3/USMTF) 

COVERAGE  TYPE 

COVERAGE 

C,7 

N 

RECDATA 

Conun:  Code  for  type  of  coverage  (Annex 

34  CH 

3/USMTF) 

EST  TIME  AIRBORNE 

ETA 

N,  4 

N 

A/C_STATUS 

Conun:  Estimated  time  A/C  airborne 

EST_TIME  OF_RETURN 

ETR 

N,  4 

N 

A/C_STATUS 

Comm:  Estime  time  . 

A/C  returns 

FUEL_REQUIREMENTS 

FUREQ 

N,  4 

N 

REFULEE 

Comm;  Total  amount 

of  fuel  req  for  the 

msn  in 

hundreds 

of  lbs 

IFF/SIF_CODES 

IFFCODE 

C,  5 

N 

ATO_MSN 

Comm:  IFF/SIF  mode 

and  code  (lx  (mode) , 

2-4N 

(code)  ) 

IMMEDIATE  AIR  REQUEST  NUMBER  IMMEDIATE 

C,  5 

Y 

IMED  AIR 

Conun:  JTAR,  ASR,  MEDEVAC  Request  Number 

LATEST  TIME  INFO  OF  VALUE  LTIOV 

C,  11 

N 

RECDATA 

Conun;  Latest  time 

in  year,  month,  day. 

hour. 

min,  time 

zone 

LOCATION 

LOCN 

C,20 

Y 

BDA 

N 

MSNLOC 

Y 

RECTGT 

N 

ROUTE 

N 

TGTLOC 

Comm:  Mission  location  (entry  list  11) 

LOCATION  TYPE 

LOCTYP 

C,  6 

N 

MSNLOC 

Comm:  Code  for  a  mission  location  (Annex  2  CH 

3/USMTF) 

MISSION  COMMENT 

MSNCMNT 

C,  22 

N 

MSNLOC 

Comm:  Comments  on 

the  mission  location 

MI S  S I ON_NUMBER 

MSNNO 

C,  8 

Y 

ATO  MSN 

Y 

REFULEE 

Y 

RIO  LOGS 

Comm:  Mission  No. 

(date,  fixed/helo,  sequence 

(25H-0009) ) 

MISSION  START 

MS TART 

C,7 

N 

RECDATA 

Conun:  Time  on  target 
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MISSION_TYPE 

MSN 

C,  5 

N 

ATO  MSN 

N 

RECDATA 

Comm:  Mission  type 

(entry  list  107A) 

NUMBER_OF_AIRCRAFT 

NO 

C,  3 

N 

REFULEE 

N 

ATO  MSN 

Comm:  Number  of  aircraft 

PERCENT_ORDNANCE_ON 

TARGET  ORD  ON  TGT 

N,2 

N 

BDA 

Comm:  Percentage  of 

Ordnance  hitting  target 

PERCENT  TARGET  DESTROYED  TGT  DESTROYED 

N,  2 

N 

BDA 

Comm:  Percentage  of 

target  destroyed 

POINT  NUMBER 

PN 

N,  2 

Y 

ROUTE 

Comm:  Numeric  sequence  given  to  the  reference  point  (1-99) 

PRIMARY_CONFIGURATION_CODE  PRICONFIG  C,5  N  ATO_MSN 

Comm:  Primary  configuration  code  for  the  aircraft 


PRIMARY_FREQUENCY  PRIFREQ  C, 8  N  CONTROL 

Comm:  Frequency  in  megahertz,  or  the  frequency  designator  (blue) 


PRIORITY 

PR 

c,i 

N 

RECDATA 

Comm:  Priority  for  the 

mission 

REFUELING_TIME 

RFLTIME 

C,7 

N 

REFULEE 

Comm;  Refueling  time  in 

day,  hour,  minute,  time 

zone 

REQUEST_NUMBER 

REQNO 

C,  6 

Y 

MSNLOC 

Y 

RECDATA 

Comm:  Preplanned  Air  Support  Request 

Number 

SECONDARY  CONFIGURATION 

CODE  SECCONFIG  C,  5 

N 

ATO_MSN 

Comm:  Secondary  configuration  code  for  the  aircraft 

SECONDARY  FREQUENCY 

SECFRQ 

C,  8 

N 

CONTROL 

Comm:  Frequency  in  megahertz,  or  by 

freqijency  designator  (blue) 

TARGET  COMMENTS 

TGTCMNT 

C,  35 

N 

TGTLOC 

Comm:  Comments  describing  the  target 

TARGET  IDENTIFIER 

TGTID 

C,20 

Y 

TGTLOC 

Comm:  Assigned  Target  Number  or  Name 

(entry  list 

11, 

table  II) 

TARGET_LENGTH 

TLGTH 

C,7 

N 

RECTGT 

Comm:  Estimated  target 

length  (Annex 

2  CH  3/USMTF) 

TARGET_TYPE 

TGTTYP 

C,  6 

N 

TGTLOC 

Comm:  Target  type  (entry  list  20) 
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RECTGT 


TARGET  WIDTH 

TWDRAD 

C,7 

N 

RECTGT 

Comm:  Estimated  width 

or  radius 

(Annex  2  CH  3/USMTF) 

TIME-OFF-TARGET 

TFT 

C,7 

Y 

EDA 

Comm:  Time  off  target 

(day,  hour 

,  minute,  time 

zone) 

TIME-OFF-TARGET 

TFT 

C,7 

N 

TGTLOC 

Comm:  Time  off  target 

(day,  hour 

,  minute,  time 

zone) 

TIME-ON-TARGET 

TOT 

C,7 

Y 

EDA 

N 

TGTLOC 

Comm:  Time  on  target 

(day,  hour. 

minute,  time 

zone) 

UNIT  SUPPORTED 

SUPPORTED  C,  9 

N 

IMED  AIR 

N 

EDA 

Comm:  Unit  supported  by  Immediate  Air  Request 
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ENTITY  AND  RELATIONSHIP  REPORT 


AIR_TASKING_ORDER  Relation  Type  -  Entity 

List  of  Attributes  (fields): 

Name  Abbreviation  Format  Key 

1.  ATO_START  ATO_START  C,7  Y 

Day,  hour,  minute,  time  zone  of  ATO  Start 

2.  ATO_STOP  ATO_STOP  C,7  Y 

Day,  hour,  minute,  time  zone  of  ATO  stop 

3.  AIR_TASKING_CODE  ATO_CODE  C,43  Y 

Code  for  air  tasking  type  (entry  list  2005) 

ASSESSES  Relation  Type  -  Relationship 

Remark:  BDAs  may  be  reported  on  a  target 
List  of  Attributes  (fields):  NONE 


BATTLE_DAMAGE_ASSESSMENT  Relation  Type  -  Entity 

List  of  Attributes  (fields): 

Name  Abbreviation  Format  Key 

1.  LOCATION  LOCN  C,20  Y 

Mission  location  (entry  list  11) 

2.  TIME-ON-TARGET  TOT  C,7  Y 

Time  on  target  (day,  hour,  minute,  time  zone) 

3.  TIME-OFF-TARGET  TFT  C,7  Y 

Time  off  target  (day,  hour,  minute,  time  zone) 

4.  PERCENT_ORDNANCE_ON_TARGETORD_ON_TGT  N.2  N 

Percentage  of  Ordnance  hitting  target 

5.  PERCENT_TARGET_DESTROYED  TGT_DESTROYED  N,2  N 

Percentage  of  target  destroyed 

6.  BDA_COMMENT  BDACMNT  C,30  N 

Description  of  results 

7.  UNn'_SUPPORTED  SUPPORTED  C,9  N 

COMPRISES  Relation  Type  -  Relationship 

Remark:  ATO  is  comprised  of  various  missions 
List  of  Attributes  (fields):  NONE 


CONTROLS  Relation  Type  -  Relationship 

Remark:  A/C  Mission  is  controlled  by  various  controlling  agencies 
List  of  Attributes  (fields):  NONE 
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CONTROL_AGENCY  Relation  Type  -  Entity 

List  of  Attributes  (fields); 


Name 

Abbreviation 

Format 

Key 

1. 

CALLSIGN 

CALLSIGN 

C,15 

Y 

Control  agency’s  callsign 

2. 

CONTROL_AGENCY 

CONT 

C,4 

N 

Code  for  the  control  agency  type  from  the  event  list 

3. 

PRIMARY_FREQUENCY 

PRIFREQ 

C,8 

N 

Frequency  in  megahertz,  or  the  frequeiKy  designator  (blue) 

4. 

SECOND  ARY_FREQUENCY 

SECFRQ 

C,8 

N 

Frequency  in  megahertz,  or  by  frequency  designator  (blue) 

5.  CONTROL_POINT  RIO_CP  C,20  N 

Location  the  A/C  is  to  check  in  with  the  control  agency 

IMMEDIATE_REQUESTS  Relation  Type  -  Entity 

List  of  Attributes  (fields): 

Name  Abbreviation  Format  Key 

1.  IMMEDIATE  AIR  REQUEST  NUMBER  IMMEDIATE  C,5  Y 

JTAR,  ASR,  MEDEVAC  Request  Number 

2.  UNIT_SL'PPORTED  SUPPORTED  C,9  N 

Unit  supported  by  Immediate  Air  Request 

INTEREST_IN  Relation  Type  -  Relationship 

Remark:  Recon  MSN  interested  in  Recon  Target  Data 
List  of  Attributes  (fields):  NONE 


MAY_DESIGNATE  Relation  Type  -  Relationship 

Remark:  Entity  Route  if  the  Mission  is  to  follow  a  certain  route 
List  of  Attributes  (fields):  NONE 
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MISSION  (ATO  MISSION) 

List  of  Attributes  (fields); 

Name  Abbreviation 

1.  M1SSI0N_NUMBER  MSNNO 

Mission  No.  (date,  fixed/helo,  sequence  (25H-0009)) 

2.  A/CCALLSIGN  C/S 

A/C  callsign 

3.  NUMBER_OF_AIRCRAFr  NO 

Number  of  Aircraft 

4.  AIRCRAFT_TYPE  TYPE 

Aircraft/helicopter  type/model/category  (entry  list  513) 

5.  MISSION_TYPE  MSN 

Mission  type  (entry  list  107 A) 

6.  ALERT_STATUS  ALR 


Alert  status  code  (Annex  33  CH  3/USMTF) 

7.  PRIMARY_CONHGURATION_CODE  PRICONHG 

Primary  configuration  code  for  the  aircraft 

8.  SECONDARY_CONnGURATION_CODE  SECCONHG 

Secondary  configuration  code  for  the  aircraft 

9.  IFF/SIF_CODES  IFFCODE 

IFF/SIF  mode  and  code  (lx  (mode).  2-4N  (code)) 

10.  EST_TIME_AIRBORNE  ETA 

Estimated  time  A/C  airborne 

1 1 .  EST_TlME_OF_RETLiRN  ETR 

Estimated  time  A/C  returns 


Relation  Type  - 

Entity 

Format 

C,8 

Key 

Y 

C42 

Y 

C,2 

N 

C.6 

N 

C,5 

N 

C,3 

N 

C,5 

N 

C,5 

N 

C,5 

N 

N,4 

N 

N,4 

N 

MISS10N_L0CATI0N  Relation  Type-  Entity 

List  of  Attributes  (fields); 

Name  Abbreviation  Format  Key 

1.  REQUEST_NUMBER  REQNO  C,6  Y 

Preplanned  Air  Support  Request  Number 

2.  LOCATION_TYPE  LOCTYP  C,6  N 

Code  for  a  mission  location  (Annex  2  CH  3/USMTF) 

3.  LOCATION  LOCN  C,20  N 

Mission  location  (entry  list  11) 

4.  ALTITUDE  ALT  C,5  N 

A/C  altitude  (Annex  2  CH  3/USMTF) 

5.  MISSION_COMMENT  MSNCMNT  C,22  N 

Comments  on  the  mission  location 


79 


RECEIVING_AIRCRAFT  Relation  Type  -  Entity 

List  of  Attributes  (fields): 


Name 

Abbreviation 

Format 

Key 

1. 

MISSION_NUMBER 

MSNNO 

C.8 

Y 

Mission  No.  (date,  fixed/helo,  sequence  (25H-()009)) 

2. 

A/CCALLSIGN 

C/S 

C42 

Y 

A/C  callsign 

3. 

NUMBER_OF_AIRCRAFT 

NO 

C,3 

N 

Number  of  aircraft 

4. 

AIRCRAFr_TYPE 

TYPE 

C,6 

N 

Aircraft/helicopter  type/model/category  (entry  list  513) 

5. 

AMOUNT_OF_FUEL 

LBSFUEL 

N,4 

N 

Amount  of  fuel  allowed  per  aircraft  in  hundreds  of  lbs 

6. 

FUEL.REQUIREMENTS 

FUREQ  N,4 

N 

Total  amount  of  fuel  req  for  the  msn  in  hundreds  of  lbs 

7. 

REFUELING_nME 

RFLTIME  C.7 

N 

Refueling  time  in  day,  hour,  minute,  time  zone 

RECONNAISSANCE 

Relation  Type  - 

Entity 

List  of  Attributes  (fields): 

Name 

Abbreviation 

Format 

Key 

1.  REQUEST_NUMBER 

REQNO 

C,6 

Y 

Preplarmed  Air  Support  Request 

Number 

2.  PRIORITY 

PR 

C.1 

N 

Priority  for  the  mission 

3.  MISSION.START 

MSTART 

C,7 

N 

Time  on  target 

4.  LATEST_TIME_INFO_OF_VALUE 

LTIOV 

C41 

N 

Latest  time  in  year,  month,  day. 

hour,  min,  time  zone 

5.  MISSION.TYPE 

MSN 

C,5 

N 

Mission  type  (entry  list  107 A) 

6.  COVERAGE_TYPE 

COVERAGE 

C,7 

N 

Code  for  type  of  coverage  (Annex  34  CH  3/USMTF) 

RECON_TARGET 

Relation  Type  - 

Entity 

List  of  Attributes  (fields): 

Name 

Abbreviation 

Format 

Key 

1.  LOCATION 

LOCN 

C,20 

Y 

Mission  location  (entry  list  1 1 ) 

2.  TARGET_LENGTH 

TLGTH 

C.7 

N 

Estimated  target  length  (Annex  2  CH  3/USMTF) 

3.  TARGET_WIDTH 

TWDRAD 

C,7 

N 

Estimated  width  or  radius  (Annex  2  CH  3/USMTF) 

REFUELS  Relation  Type  -  Relationship 

Remark:  Refueling  Mission  Refuels  Receiving  Aircraft 
List  of  Attributes  (fields):  NONE 
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REQLTESTS  Relation  Type  -  Relationship 

Remark.  Immediate  air  support  requests  Mission  from  ATO  to  perform  List  of  Attributes  (fields): 

NONE 


R10_L0GS  Relation  Type  -  Entity 

List  of  Attributes  (fields); 

Name  Abbreviation  Format 

1.  M1SSI0N_NUMBER  MSNNO  C,8 

Mission  No.  (date,  fixed/helo,  sequence  (25H-0009)) 

2.  ACTUAL_TIME_OF_ARRIVAL  ATA  N,4 

Actual  time  A/C  reported  in  with  DASC 

3.  A(rrUAL_TIME_OF_RETURN  ATR  N,4 

Actual  time  A/C  repotted  out  with  DASC 

ROLTE  Relation  Type  -  Entity 

List  of  Attributes  (fields): 

Name  Abbreviation  Format 

1.  POINT_NUMBER  PN  N,2 

Numeric  sequence  given  to  the  reference  point  (1-99) 

2.  CONTROL_PO'Nr_T3[TE  CPTYP  C,3 

Code  for  ti  >  route  point  type  (Annex  2  CH  3/USMTF) 

3.  LOCATION  LOCN  C.20 

Mission  location  (entry  list  11) 

4.  ARRIVAL_TIME  ATIME  C,7 

Arrival  time  (Annex  2  CH  3/USMTF) 


Key 


Key 


Y 

N 

N 


Y 

N 

N 

N 


TARGET_LOCATION  Relation  Type  -  Entity 

List  of  Attributes  (fields): 


Name 

Abbreviation 

Format  Key 

1. 

TARGETJDENTIFIER 

TGTID 

C,20 

Y 

Assigned  Target  Number  or  Name  (entry  list  11,  table  11) 

2. 

TlME-ON-T/>kRGET 

TOT 

C,7 

N 

Time  on  target  (day,  hour,  minute,  time  zone) 

3. 

TIME-OFF-TARGET 

TFT 

C.7 

N 

Time  off  target  (day,  hour,  minute,  time  zone) 

4. 

TARGET_TYPE 

TGTTYP 

C,6 

N 

Target  type  (entry  list  20) 

5. 

LOCATION 

LOCN 

C,20 

N 

Mission  location  (entry  list  U) 

6. 

TAJRGET_COMMENTS 

TGTCMNT 

C,35 

N 

Comments  describing  the  target 


UPDATES  Relation  Type  -  Relationship 

Remark:  TAD/HD  logs  append/update  ATO  with  actual  data  List 
List  of  Attributes  (fields);  NONE 
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CARDINALITY  and  CELL  LINKS  REPORT 


Connections  Listing  by  Cell 


Entity  AIR_TASKING_ORDER 

to  Entity  MISSION 

through  Relationship  COMPRISES 

abbrev:  ATO 
abbrev;  ATO_MSN 
abbrev:  COMP 

CARDINALITY 
lower  =  1 
upper  =  I 
lower  n  =  1 
upper  n  =  1 

CARDINALITY 
lower  =  1 
upper  =  N 
lower  n  =  1 
upper  n  = 

Entity  AIR_TASKING_ORDER 
to  Entity  RJO_LOGS 
through  Relationship  UPDATES 

abbrev;  ATO 
abbrev:  RIO_LOGS 
abbrev:  UPDATES 

CARDINALITY 
lower  =  1 
upper  =  1 
lower  n  =  1 
upper  n  =  1 

CARDINALITY 
lower  =  1 
upper  =  N 
lower  n  =  1 
upper  n  = 

Entity  MISSION 

to  Entity  IMMEDIATE_REQUESTS 
through  Relationship  REQUESTS 

abbrev.  ATO  MSN 
abbrev:  IMED  AIR 
abbrev:  REQUESTS 

CARDINALITY 
lower  =  1 
upper  =  N 
lower  n  =  1 
upper  n  = 

CARDINALITY 
lower  =  0 
upper  =  N 
lower  n  =  0 
upper  n  = 
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Entity  MISSION  abbrev:  ATO  MSN 

parent  of  Entity  RECONNAISSANCE  abbrev:  RECDATA 
through  ISA  RELATIONSHIP  MISSION  abbrev:  ATO  MSN 


CARDINALITY 
lower  =  1 
upper  =  1 
lower  n=  1 
upper  n=  1 


CARDINALITY 
lower  =  0 
upper  =  N 
lower  n  =  0 
upper  n  = 


Entity  MISSION  abbrev:  ATO  MSN 

parent  of  Entity  MISSI0N_L0CAT10N  abbrev:  MSNLOC 
through  ISA  RELATIONSHIP  MISSION  abbrev;  ATO  MSN 

CARDINALITY  CARDINALITY 

lower  =  1  lower  =  0 

upper  =  1  upper  =  N 

lower  n  =  1  lower  n  =  0 

upper  n  =  1  upper  n  = 


Entity  MISSION  abbrev;  ATO_MSN 

to  Entity  AIR_TASKING_ORDER  abbrev:  ATO 

through  Relationship  COMPRISES  abbrev:  COMP 


CARDINALITY 
lower  =  1 
upper  =  N 
lower  n  =  1 
upper  n  = 


CARDINALITY 
lower  =  1 
upper  =  1 
lower  n  =  1 
upper  n  =  1 


Entity  MISSION  abbrev;  ATO_MSN 

to  Entity  ROUTE  abbrev;  ROUTE 

through  Relationship  MAY_DESIGNATE  abbrev;  DESIGNAT 


CARDINALITY 
lower  =  1 
upper  =  1 
lower  n  =  1 
upp>er  n  =  1 


CARDINALITY 
lower  =  0 
upper  =  N 
lower  n  =  0 
upper  n  = 
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Entity  MISSION  abbrev:  ATO  MSN 

parent  of  Entity  TARGET_LOCATION  abbrev;  TGTLOC 
through  ISA  RELATIONSHIP  MISSION  abbrev:  ATO  MSN 


CARDINALITY 
lower  =  1 
upper  =  I 
lower  n  =  1 
upper  n  =  1 


CARDINALITY 
lower  =  0 
upper  =  N 
lower  n  =  0 
upper  n  = 


Entity  MISSION  abbrev;  ATO_MSN 

to  Entity  CONTROL_AGENCY  abbrev:  CONTROL 

through  Relationship  CONTROLS  abbrev;  CONTROLS 


CARDINALITY 
lower  =  1 
upper  =  1 
lower  n  =  1 
upper  n  =  1 


CARDINALITY 
lower  =  0 
upper  =  N 
lower  n  =  0 
upper  n  = 


Entity  BATTLE_DAMAGE_ASSESSMENT  abbrev:  BDA 
to  Entity  TARGET_LOCATION  abbrev:  TGTLOC 

through  Relationship  ASSESSES  abbrev:  ASSESSES 


CARDIN  ALFTY 
lower  =  0 
upper  =  N 
lower  n  =  0 
upper  n  = 


CARDINALITY 
lower  =  I 
upper  =  1 
lower  n  =  1 
upper  n  =  I 


Entity  CONTROL_AGENCY  abbrev;  COI'ITROL 

to  Entity  MISSION  abbrev;  ATO_MSN 

through  Relationship  CONTROLS  abbrev:  CONTROLS 


CARDINALITY 
lower  =  0 
upper  =  N 
lower  n  =  0 
upper  n  = 


CARDINALITY 
lower  =  1 
upper  =  I 
lower  n  =  I 
upper  n  =  1 
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Entity  IMMED1ATE_REQUESTS 

to  Entity  MISSION 

through  Relationship  REQUESTS 


abbrev;  IMED  AIR 
abbrev:  ATO_MSN 
abbrev;  REQUESTS 


CARDINALITY 
lower  =  0 
upper  =  N 
lower  n  =  0 
upper  n  = 


CARDINALITY 
lower  =  1 
upper  =  N 
lower  n  =  1 
upper  n  = 


Entity  MISSION_LOCATION  abbrev;  MSNLOC 

to  Entity  RECEIVING_A1RCRAFT  abbrev;  REFULEE 

through  Relationship  REFUELS  abbrev:  REFUELS 


CARDINALITY 
lower  =  1 
upper  =  1 
lower  n  =  1 
upper  n  =  1 


CARDINALITY 
lower  =  0 
upper  =  N 
lower  n  =  0 
upper  n  = 


Entity  MISSION_LOCATION  abbrev;  MSNLOC 

child  of  Entity  MISSION  abbrev:  ATO_MSN 

through  ISA  RELATIONSHIP  MISSION  abbrev;  ATO.MSN 


CARDINALITY 
lower  =  0 
upper  =  N 
lower  n  =  0 
upper  n  = 


CARDINALITY 
lower  =  1 
upper  =  1 
lower  n  =  1 
upper  n  =  1 


Entity  RECONNAISSANCE  abbrev;  RECDATA 

to  Entity  RECON_TARGET  abbrev:  RECTGT 

through  Relationship  INTEREST_IN  abbrev;  INT 


CARDINALITY 
lower  =  1 
upper  =  N 
lower  n  =  1 
upper  n  = 


CARDINALITY 
lower  =  1 
upper  =  N 
lower  n  =  1 
upper  n  = 
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Entity  RECONNAISSANCE  abbrev:  RECDATA 

child  of  Entity  MISSION  abbrev:  ATO  MSN 

through  ISA  RELATIONSHIP  MISSION  abbrev:  ATO_MSN 


CARDINALITY 
lower  =  0 
upper  =  N 
lower  n  =  0 
upper  n  = 


CARDINALITY 
lower  =  1 
upper  =  1 
lower  n  =  1 
upper  n  =  1 


Entity  RECON  TARGET  abbrev;  RECIGT 

to  Entity  RECONNAISSANCE  abbrev:  RECDATA 

through  Relationship  INTEREST_IN  abbrev;  INT 


CARDINALITY 
lower  =  1 
upper  =  N 
lower  n  =  1 
upper  n  = 


CARDINALITY 
lower  =  1 
upper  =  N 
lower  n  =  1 
upper  n  = 


Entity  RECEISONG.AIRCRAFT  abbrev;  REFULEE 

to  Entity  MISSION.LOCATION  abbrev;  MSNLOC 

through  Relationship  REFUELS  abbrev;  REFUELS 


CARDINALITY 
lower  =  0 
upper  =  N 
lower  n  =  0 
upper  n  = 


CARDINALITY 
lower  =  1 
upper  =  1 
lower  n  =  1 
upper  n  =  1 


Entity  RIOLOGS  abbrev;  RIO_LOGS 

to  Entity  AIR_TASKING_ORDER  abbrev;  ATO 

through  Relationship  UPDATES  abbrev;  UPDATES 


CARDINALITY 
lower  =  1 
upper  =  N 
lower  n  =  1 
upper  n  = 


CARDINALITY 
lower  =  1 
upper  =  1 
lower  n  =  1 
upper  n  =  1 
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Entity  ROUTE  abbrev:  ROUTE 

to  Entity  MISSION  abbrev:  ATO_MSN 

through  Relationship  MAY_DESIGNATE  abbrev:  DESIGNAT 


CARDINALFTY 
lower  =  0 
upper  =  N 
lower  n  =  0 
upper  n  = 


CARDINALITY 
lower  =  1 
upper  =  1 
lower  n  =  1 
upper  n  =  1 


Entity  TARGET_LOCATION  abbrev:  TGTLOC 

chUd  of  Entity  MISSION  abbrev:  ATO_MSN 

through  ISA  RELATIONSHIP  MISSION  abbrev:  ATO_MSN 


CARDINALITY 
lower  =  0 
upper  =  N 
lower  n  =  0 
upper  n  = 


CARDINALITY 
lower  =  1 
upper  =  1 
lower  n  =  1 
upper  n  =  1 


Entity  TARGET_LOCATION  abbrev:  TGTLOC 

to  Entity  BATTLE_DAMAGE_ASSESSMENT  abbrev:  BDA 
through  Relationship  ASSESSES  abbrev:  ASSESSES 


CARDINALITY 
lower  =  1 
upper  =  1 
lower  n  =  1 

upper  n=  1 


CARDINALITY 
lower  =  0 
upper  =  N 
lower  n  =  0 
upper  n  = 


ISA  RELATIONSHIP  MISSION’S 
parent  r.  Entity  MISSION 

ISA  RELATIONSHIP  MISSION’S 
child  is  Entity  TARGET_LOCATION 

ISA  RELATIONSHIP  ITISSION’s 
child  is  Entity  MISSION_LOCATlON 


abbrev:  ATO_MSN 
abbrev:  ATO_MSN 

abbrev:  ATO_MSN 
abbrev:  TGTLOC 

abbrev:  ATO_MSN 
abbrev:  MSNLOC 
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ISA  RELATIONSHIP  MISSION’S  abbrev:  ATO_MSN 

parent  is  Entity  MISSION  abbrev:  ATO_MSN 


ISA  RELATIONSHIP  MISSION’S  abbrev:  ATO_MSN 

child  is  Entity  RECONNAISSANCE  abbrev:  RECDATA 


ISA  RELATIONSHIP  MISSION’S  abbrev;  ATO_MSN 

parent  is  Entity  MISSION  abbrev:  ATO_MSN 


Relationship  ASSESSES  abbrev:  ASSESSES 

to  Entity  TARGET_LOCATION  abbrev:  TGTLOC 

CARDINALITY 
lower  =  1 
upper  =  1 
lower  n  =  1 
upper  n  =  1 


Relationship  ASSESSES  abbrev:  ASSESSES 

to  Entity  BATTLE_DAMAGE_ASSESSMENT  abbrev:  BDA 

CARDINALITY 
lower  =  0 
upper  =  N 
lower  n  =  0 
upper  n  = 


Relationship  COMPRISES  abbrev;  COMP 

to  Entity  AIR_TASKING_ORDER  abbrev:  ATO 

CARDINALITY 
lower  =  1 
upper  =  1 
lower  n  =  1 
upper  n  =  1 
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Relationship  COMPRISES 
to  Entity  MISSION 

CARDINALITY 
lower  =  1 
upper  =  N 
lower  n  =  1 
upper  n  = 


Relationship  CONTROLS 
to  Entity  MISSION 

CARDINALITY 
lower  =  1 
upper  =  1 
lower  n  =  1 
upper  n  =  1 


Relationship  CONTROLS 
to  Entity  CONTROL_AGENCY 

CARDINALITY 
lower  =  0 
upper  =  N 
lower  n  =  0 
upper  n  = 


Relationship  MAY-DESIGNATE 
to  Entity  MISSION 

CARDINALITY 
lower  =  1 
upper  =  1 
lower  n  =  1 
upper  n  =  1 


abbrev:  COMP 
abbrev:  ATO  MSN 


abbrev;  CONTROLS 
abbrev;  ATO_MSN 


abbrev;  CONTROLS 
abbrev;  CONTROL 


abbrev;  DESIGNAT 
abbrev;  ATO_MSN 
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Relationship  MAY_DESIGNATE 
to  Entity  ROUTE 

CARDINALITY 
lower  =  0 
upper  =  N 
lower  n  =  0 
upper  n  = 


Relationship  INTEREST_IN 
to  Entity  RECON_TARGET 

CARDINALITY 
lower  =  1 
upper  =  N 
lower  n  =  1 
upper  n  = 


Relationship  INTERESTJN 
to  Entity  RECONNAISSANCE 

CARDINALITY 
lower  =  1 
upper  =  N 
lower  n  =  1 
upper  n  = 


Relationship  REFUELS 

to  Entity  RECEIVING_AIRCRAFT 

CARDINALITY 
lower  =  0 
upper  =  N 
lower  n  =  0 
upper  n  = 


abbrev:  DESIGNAT 
abbrev:  ROUTE 


abbrev:  INT 
abbrev:  RECTGT 


abbrev:  INT 
abbrev:  RECDATA 


abbrev:  REFUELS 
abbrev:  REFULEE 
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Relationship  REFUELS 
to  Entity  MISSION_LOCATION 

CARDINALITY 
lower  =  1 
upper  =  1 
lower  n  =  1 
upper  n  =  1 


Relationship  REQUESTS 

to  Entity  IMMEDIATE_REQUESTS 

CARDINALITY 
lower  =  0 
upper  =  N 
lower  n  =  0 
upper  n  = 


Relationship  REQUESTS 
to  Entity  MISSION 

CARDINALITY 
lower  =  1 
upper  =  N 
lower  n  =  1 
upper  n  = 


Relationship  UPDATES 
to  Entity  AIR_TASKING_ORDER 

CARDINALITY 
lower  =  1 
upper  =  1 
lower  n  =  1 
upper  n  =  1 


abbrev;  REFUELS 
abbrev:  MSNLOC 


abbrev:  REQUESTS 
abbrev:  IMED  AIR 


abbrev:  REQUESTS 
abbrev:  ATO_MSN 


abbrev:  UPDATES 
abbrev:  ATO 
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Relationship  UPDATES 
to  Entity  RIO_LOGS 


abbrev;  UPDATES 
abbrev:  RIO  LOGS 


CARDINALITY 
lower  =  1 
upper  =  N 
lower  n  =  1 
upper  n  = 
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APPENDIX  E:  E-R  DESIGNER  RELATIONAL  SCHEMA 


CONTROL_AGENCY  {callsign  :  control_agency,  primary_firequency,  secondary _ftequency, 
controLpoint) 

AIR_TASKING_ORDER  {ato  start,  ato  stop,  air  tasking  code  :) 

ROUTE  {miss ion  number,  point  number  :  control_point_type,  location,  anival_time) 

RIO_LOGS  {mission jtumber  :  actual_time_of_anival,  actual_time_of_retum) 

RECEIVING_ AIRCRAFT  {mission  number,  alc  callsign  :  number_of_aiTcraft,  aircraft_type, 
aniount_of_fuel,  fuel_requirements,  refueling_time) 

BATTLE_DAMAGE_ASSESSMENT  {location,  time-on-target :  time-off-target, 
percent_ordnance_on_target,  percent_target_destroyed,  bda_comment,  unit_supported) 

MISSION_LOCATION  {request jiumber,  mission jiumber,  atcjcallsign  :  location_type, 
location,  altitude,  mission_comment) 

MISSION  {mission  Jtumber,  a/c_call$ign,  request  number  ;  number_of_aircraft,  aircraft_type, 
mission_type,  alert_status,  primaty_configuration_code,  secondary_configuration_code, 
iff/sif_codes,  est_time_airbome,  est_time_of_retum) 

TARGET_LOCATION  {target Jdentifier,  mission  number,  aic  callsign,  request  number  : 
time-on-target,  time-off-target,  target_type,  location,  target_comments) 

RECONNAISSANCE  {request jtumber  :  priority,  mission_start,  mission_stop, 
latest_time_info_of_value,  mission_type,  coverage_type) 

IMMEDIATE_REQUESTS  {immediate  jjiir_request jtumber  :  unit_supported) 

RECON_TARGET  {location  :  target_length,  tafget_width) 

- Key - 

RELATION  {primary  key  attribute(s)  ;  non-key  attribute(s)) 
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COMPRISES  {atojstart,  ato_stop,  air  jasking_codc,  mission jtumber,  ale  callsign  :) 
ASSESSES  {target  jdentifier,  location,  time-on-target,  time-ojf-target ;) 

CONTROLS  {mission  number ,  a/c  callsign,  callsign  :) 

REQUESTS  {immediate _air_reque St  number,  mission jiumber,  ale  callsign  :) 
INTEREST_IN  {location,  request  number  :) 

MAY_DESIGNATE  {mission jtumber,  alcjcallsign,  point jiumber  :) 

UPDATES  {ato  start,  ato  stop,  air  tasking  code,  mission  number  :) 

REFUELS  {mission  Jtumber,  alcjallsign,  request  jiumber  :) 
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E-R  Designer  Relational  Schema  File  Format 


CONTROL_AGENCY  5  1 

CALLSIGN  C,15 

CONTROL_AGENCY  C,4 

PRIMARY_FREQUENCY  C,8 

SECONDARY_FREQUENCY  C,8 

CONTOOL_POINT  C,20 

AIR_TASKING_ORDER  3  3 

ATO_START  C,7 

ATO_STOP  C,7 

AIR_TASKING_CODE  C,43 

ROUTE  5  2 

MISSION_NUMBER  C,8 

POINT_NUMBER  n]2 

CONTROL_POINT_TYPE  C,3 

LOCATION  C,20 

ARRIVAL.TIME  C,7 

RIO.LOGS  3  1 

MISSION.NUMBER  C,8 

ACTUAL_TIME_OF_ARRIVAL  N,4 

ACTUAL_TIME_OF_RETURN  N,4 

RECEIVING_AIRCRAFT  7  2 

MISSION_NUMBER  C,8 

A/C_CALLSIGN  C,12 

NUMBER_OF_AIRCRAFT  N,2 

AIRCRAFT.TYPE  C,6 

AMOUNT_OF_FUEL  N,4 

FUEL_REQUIREMENTS  N,4 

REFUELING_TIME  C,7 

- Key - 

Relation  #  of  attributes,  #  of  primary  key  attributes 

Attribute  field  format,  max  length 


C  (character) 
N  (numeric) 
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BATrLE_DAMAGE_ASSESSMENT  7  3 

LOCATION  C,20 

TIME-ON-TARGET  C,7 

TIME-OFF-TARGET  C,7 

PERCENT_ORDNANCE_ON_TARGET  N,2 
PERCENT_TARGET_DESTROYED  N,2 

BDA_COMMENT  C,30 

UNIT_SUPPORTED  C,9 

MISSION_LOCATION  7  3 

REQUEST_NUMBER  C,6 

MISSION_NUMBER  C,8 

A/C_CALLSIGN  C,12 

LOCATION_TYPE  C,6 

LOCATION  C,20 

ALTITUDE  C,5 

MISSION_COMMENT  C,22 

MISSION  13  3 

MISSION_NUMBER  C,8 

A/C_CALLSIGN  C,12 

REQUEST  NUMBER  C,6 

NUMBER_OF_AIRCRAFT  C,2 

AIRCRAFT_TYPE  C,6 

MISSION_TYPE  C,5 

ALERT_STATUS  C,3 

PRIMARY_CONnGURATION_CODE  C,5 
SECONDARY_CONnGURATION_CODE  C,5 
IFF/SIF_CODES  C,5 

EST_TIME_AIRBORNE  N,4 

EST_TIME_OF_RETURN  N,4 

TARGET.LOCATION  9  4 

TARGETJDENnnER  C,20 

MISSION_NUMBER  C,8 

A/C_CALLSIGN  C,12 

REQUEST.NUMBER  C,6 

TIME-ON-TARGET  C,7 

TIME-OFF-TARGET  C,7 

TARGET_TYPE  C,6 

LOCATION  C,20 

TARGET_COMMENTS  C,35 
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RECONNAISSANCE  7  1 

REQUEST^NUMBER  C,6 

PRIORITY  C,1 

MISSION_START  C,7 

MISSION.STOP  C,7 

LATEST_TIME_INFO_OF_VALUE  C,ll 

MISSION_TYPE  C,5 

COVERAGE_TYPE  C,7 

IMMEDIATE_REQUESTS  2  1 

IMMEDIATE_AIR_REQIJEST_NUMBER  C,5 
UNIT_SUPPORTED  C,9 

RECON_TARGET  3  1 

LOCATION  C,20 

TARGET_LENGTH  C,7 

TARGET_WIDTH  C,7 

COMPRISES  5  5 

ATO_START  C,7 

ATO_STOP  C,7 

AIR_TASKING_CODE  C,43 

MISSION_NUMBER  C,8 

A/C_CALLSIGN  C,12 

ASSESSES  4  4 

TARGETJDENTIFIER  C,20 

LOCATION  C,20 

TIME-ON-TARGET  C,7 

TIME-OFF-TARGET  C,7 

CONTROLS  3  3 

MISSION_NUMBER  C,8 

A/C_CALLSIGN  C,12 

CALLSIGN  C,15 

REQUESTS  3  3 

IMMEDIATE_AIR_REQUEST_NUMBER  C,5 
MISSION_NUMBER  C,8 

A/C_CALLSIGN  C,12 
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INTERESTJN  2  2 

LOCATION  C,20 

REQUEST_NUMBER  C,6 

MAY_DESIGNATE  3  3 

MISSION_NUMBER  C,8 

A/C_CALLSIGN  C,12 

POINT_NUMBER  N,2 

UPDATES  4  4 

ATO_START  C,7 

ATO_STOP  C,7 

AIR_TASKING_CODE  C,43 

MISSION_NUMBER  C,8 

REFUELS  3  3 

MISSION_NUMBER  C,8 

A/C_CALLSIGN  C,12 

REQUEST_NUMBER  C,6 
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APPENDIX  F:  NORMALIZER  LOG 


ENTERING  FD  FOR  THE  RELATION;  CONTROL_AGENCY 

CONTROL_AGENCY  (CALLSIGN,  CONTROL_AGENCY,  PRIMARY_FREQUENCY, 
SECONDARY_FREQUENCY,  CONTROL_POINT) 


Candidate  keys= 
1  CALLSIGN 


All  Fd’s  entered  for  this  relation 

1;  CALLSIGN  — >  CONTROL_AGENCY  PRIMARY_FREQUENCY 
SECOND  ARY_FREQUENCY 
2:  CONTROL_AGENCY  — >  CONTROL_POINT 


RESULT  OF  CHECKING  NORMAL  FORMS  FOR  RELATION  (CONTROL_AGENCY) 

NOTATION:  Y  :  SATISFACTORY  N  :  NOT  SATISFACTORY 

FD  no.  BCNF  3NF 

1  Y  Y 

2  N  N 

Removing  the  EXTRANEOUS  ATTRIBUTES  begins . 

No  extraneous  attribute  found 

SEARCHING  for  REDUNDANT  FDs  begins . 

NO  redundant  FD  found. 

CONSTRUCTION  OF  RELATIONS  begins . 

The  relation  (CONTROL_AGENCY)  was  SYNTHESIZED  and  MINIMIZED  as  foUows: 
Original  Relation  is  decomposed  to  : 

(CALLSIGN  :  CONTROL_AGENCY,  PRIMARY_FREQUENCY, 

SECOND  ARY_FREQUENCY) 

(CONTROL_AGENCY  :  CONTROL_POINT) 

Checking  for  LOSSLESS  JOIN  begins.... 

Decomposition  is  LOSSLESS 
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The  relations  are  SYNTHESIZED, 

FD-PRESERVING.  LOSSLESS,  and  MINIMAL  relations 

Now,  ASSIGN  the  relation  name  for  new  relation(s). 

New  Decomposed  Relations: 

(CALLSIGN  :  CONTROL_AGENCY,  PRIMARY_FREQUENCY, 
SECOND  ARY_FREQUENCY) 

Enter  A  new  name  for  the  relation  above  ===> 

New  Decomposed  Relations: 

(CONTROL.AGENCY  :  CONTROL_POINT) 

Enter  A  new  name  for  the  relation  above  => 

FDs  after  Normalization 

1.  CALLSIGN  — >  CONTROL_AGENCY  PRIMARY_FREQUENCY 
SECONDARY_FREQUENCY 

2.  CObrmOL_AGENCY  — >  CONTROL_POINT 


ENTERING  FD  FOR  THE  RELATION:  AIR_TASKING_ORDER 
AIR_TASKING_ORDER  (ATO_START,  ATO_STOP,  AIR_TASKING_CODE) 


ENTERING  FD  FOR  THE  RELATION:  ROUTE 

ROUTE  (MISSION_NUMBER,  POINT.NUMBER,  CONTROL_POINT_TYPE,  LOCATION, 
ARRIVAL_T1ME) 


ENTERING  FD  FOR  THE  RELATION:  RIO_LOGS 

RIO_LOGS  (MISSION_NUMBER,  ACrUAL_TIME_OF_ARRIVAL, 
ACTUAL_TIME_0F_RETURN) 


ENTERING  FD  FOR  THE  RELATION:  RECErVING_AIRCRAFT 

RECEIVING.AIRCRAFT  (MISSION_NUMBER,  A/C_CALLSIGN, 
NUMBER_OF_AIRCRAFT,  AIRCRAFT.TYPE,  AMOUNT_OF_FUEL, 
FUEL.REQUIREMENTS,  REFUELING_TIME) 

Candidate  keys= 

1  MISSION_NUMBER  A/C_CALLSIGN 
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All  Fd's  entered  for  this  relation 

1;  MISSION_NUMBER  A/C_CALLSIGN  — >  NUMBER_OF_AIRCRAFT 
AIRCRAFT_TYPE  AMOUNT_OF_FUEL  REFUELING_TIME 

2:  NUMBER_OF_AIRCRAFT  AMOUNT_OF_FUEL  — >  FUEL_REQUIREMENTS 


RESULT  OF  CHECKING  NORMAL  FORMS  FOR  RELATION 
(RECEIVING_AIRCRAFT) 

NOTATION:  Y  :  SATISFACTORY  N  :  NOT  SATISFACTORY 

FD  no.  BCNF  3NF 

1  Y  Y 

2  N  N 

Removing  the  EXTRANEOUS  ATTRIBUTES  begins . 

No  extraneous  attribute  found 


SEARCHING  for  REDUNDANT  FDs  begins . 

NO  redundant  FD  found. 

CONSTRUCTION  OF  RELATIONS  begins . 

The  relation  (RECEIVING.AIRCRAFT)  was  SYNTHESIZED  and  MINIMIZED  as  follows: 
Original  Relation  is  decomposed  to  : 

(MISSION_NUMBER,  A/C_CALLSIGN  ;  NUMBER_OF_AIRCRAFT,  AIRCRAFT.TYPE, 
AMOUNT_OF_FUEL,  REFUELING.TIME) 

(NUMBER_OF_AIRCRAFT,  AMOUNT_OF_FUEL  :  FUEL_REQUIREMENTS) 

Checking  for  LOSSLESS  JOIN  begins.... 

Decomposition  is  LOSSLESS 
The  relations  are  SYNTHESIZED, 

FD-PRESERVING,  LOSSLESS,  and  MINIMAL  relations 

Now,  ASSIGN  the  relation  name  for  new  relation(s). 

New  Decomposed  Relations: 

(MISSION_NUMBER,  A/C_CALLSIGN  :  NUMBER_OF_AIRCRAFT,  AIRCRAFT.TYPE, 
AMOUNT_OF_FUEL,  REFUELING_'nME) 

Enter  A  new  name  for  the  relation  above  ==> 

New  Decomposed  Relations: 

(NUMBER_OF_AIRCRAFT,  AMOUNT_OF_FUEL  :  FUEL_REQUIREMENTS) 

Enter  A  new  name  for  the  relation  above  ===> 
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FDs  after  Normalization 

1.  MISSION_NUMBER  A/C_CALLSIGN  — >  NUMBER_OF_AIRCRAFT 
AIRCRAFT_TYPE  AMOUNT_OF_FUEL  REFUELING_TIME 

2.  NUMBER_OF_AIRCRAFT  AMOUNT_OF_FUEL  — >  FUEL_REQUIREMENTS 


ENTERING  FD  FOR  THE  RELATION;  BATTLE_DAMAGE_ASSESSMENT 

BATTLE_DAMAGE_ASSESSMENT  (LOCATION,  TIME-ON-TARGET, 
TIME-OFF-TARGET,  PERCENT_ORDANANCE_ON_TARGET, 
PERCENT_TARGET_DESTROYED,  BDA_COMMENT,  UNIT_SUPPORTED) 


ENTERING  FD  FOR  THE  RELATION:  MISSION_LOCATION 

MISSION_LOCATION  (MISSION_NUMBER,  A/C_CALLSIGN,  REQUEST_NUMBER, 
LOCATION_TYPE,  LOCATION,  ALTITUDE,  MISSION_COMMENT) 


Candidate  keys= 

1  MISSION_NUMBER  A/C_CALLSIGN  REQUEST_NUMBER 

All  Fd’s  entered  for  this  relation 
1.  REQUEST.NUMBER  — >  LOCATION.TYPE  LOCATION 

2:  MISSION_NUMBER  A/C_CALLSIGN  REQUEST.NUMBER  — >  ALTITUDE 
MISSION_COMMENT 


RESULT  OF  CHECKING  NORMAL  FORMS  FOR  RELATION  (MISSION_LOCATION) 

NOTATION;  Y  :  SATISFACTORY  N  ;  NOT  SATISFACTORY 
FD  no.  BCNF  3NF 

1  N  N 

2  Y  Y 

Removing  the  EXTRANEOUS  ATTRIBUTES  begins . 

No  extraneous  attribute  found 


SEARCHING  for  REDUNDANT  FDs  begins 
NO  redundant  FD  found. 


CONSTRUCTION  OF  RELATIONS  begins 
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The  relation  (MISSION_LOCATION)  was  SYNTHESIZED  and  MINIMIZED  as  foUows 
Original  Relation  is  decomposed  to  ; 

(REQUEST_NUMBER  :  LOCATION_TYPE,  LOCATION) 

(MISSION_NUMBER,  A/C_CALLSIGN,  REQUEST_NUMBER  :  ALTITUDE, 
MISSION_COMMENT) 

Checking  for  LOSSLESS  JOIN  begins  ... 

Decomposition  is  LOSSLESS 
The  relations  are  SYNTHESIZED, 

FD-PRESERVING,  LOSSLESS,  and  MINIMAL  relations 

Now,  ASSIGN  the  relation  name  for  new  relation(s). 

New  Decomposed  Relations: 

(REQUEST_NUMBER  :  LOCATION_TYPE,  LOCATION) 

Enter  A  new  name  for  the  relation  above  ==> 

New  Decomposed  Relations: 

(MISSION_NUMBER,  A/C_CALLSIGN,  REQUEST_N UMBER  :  ALTITUDE, 
MISSION_COMMENT) 

Enter  A  new  name  for  the  relation  above  ==> 


FDs  after  Normalization 

1.  REQUEST.NUMBER  — >  LOCATION_TYPE  LOCATION 

2.  MISSION_NUMBER  A/C_CALLSIGN  REQUEST_NUMBER  — >  ALTITUDE 
MISSION.COMMENT 


ENTERING  FD  FOR  THE  RELATION:  MISSION 

MISSION  (MISSION_NUMBER,  A/C_CALLSIGN,  REQUEST_NUMBER, 
NUMBER_OF_AIRCRAFT,  AIRCRAFT_TYPE,  MISSION_TYPE,  ALERT_STATUS, 
PRIMARY_CONFIGURATION_CODE,  SECONDARY_CONFIGURATION_CODE, 
IFF/SIF_CODES,  EST_TlME_AIRBORNE,  EST_TIME_OF_RETURN) 


Candidate  keys= 

1  MISSION_NUMBER  A/C_CALLSIGN  REQUEST_NUMBER 
All  Fd’s  entered  for  this  relation 

1:  MISSION_NUMBER  A/C_CALLSIGN  — >  NUMB ER_OF_ AIRCRAFT 
AIRCRAFT_TYPE  MISSION_TYPE  ALERT.STATUS 

PRIMARY_CONnGURA'nON_CODE  SECONDARY_CONnGURATION_CODE 
IFF/SIF_CODES 

2:  A/C_CALLSIGN  — >  NUMB ER_OF_ AIRCRAFT  AIRCRAFT_TYPE 
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3:  MISSION  NUMBER  — >  MISSION  TYPE 


RESULT  OF  CHECKING  NORMAL  FORMS  FOR  RELATION  (  MISSION  ) 
NOTATION:  Y  :  SATISFACTORY  N  :  NOT  SATISFACTORY 

FD  no.  BCNF  3NF 

1  N  N 

2  N  N 

3  N  N 

Removing  the  EXTRANEOUS  ATTRIBUTES  begins . 

Extraneous  attribute(s)  found 

***  Before  Removing  Extraneous  Attributes;  *** 

1:  MISSION_NUMBER  A/C_CALLSIGN  — >  NUMBER_OF_AIRCRAFT 
AIRCRAFT_TYPE  MISSION_TYPE  ALERT_STATUS 

PRIMARY.CONnGURATION.CODE  SECONDARY.CONHGURATION.CODE 
IFF/SIF_CODES  EST_TIME_AIRBORNE  EST_TIME_OF_RETURN 
2:  A/C_CALLSIGN  — >  NUMB ER_OF_ AIRCRAFT  AIRCRAFT_TYPE 
3:  MISSION_NUMBER  — >  MISSION_TYPE 
***  After  Removing  Extraneous  Attributes:  *** 

1:  MISSION_NUMBER  A/C_CALLSIGN  — >  ALERT.STATUS 
PRIMARY_CONFIGURATION_CODE  SECONDARY.CONHGURATION.CODE 
IFF/SIF_CODES  EST_TIME_ AIRBORNE  EST_TIME_OF_RETURN 
2:  A/C_CALLSIGN  — >  NUMBER_OF_AIRCRAFT  AIRCRAFT.TYPE 
3:  MISSION_NUMBER  — >  MISSION_TYPE 

SEARCHING  for  REDUNDANT  FDs  begins . 

NO  redundant  FD  found. 


CONSTRUCTION  OF  RELATIONS  begins . 

The  relation  (MISSION)  was  SYNTHESIZED  and  MINIMIZED  as  follows: 
Original  Relation  is  decomposed  to  ; 

(MISSION_NUMBER,  A/C_CALLSIGN,  REQUEST_NUMBER) 
(MISSION_NUMBER,  A/C_CALLSIGN  :  ALERT_STATUS, 
PRIMARY_CONnGURATION_CODE,  SECONDARY.CONHGURATION.CODE, 
IFF/SIF_CODES,  EST_'nME_AIRBORNE,  EST_TIME_OF_RETURN) 
(A/C_CALLSIGN  :  NUMB  ER_OF_ AIRCRAFT,  AIRCRAFT_TYPE) 
(MISSION_NUMBER  :  MISSION_TYPE) 

Checking  for  LOSSLESS  JOIN  begins.... 


Decomposition  is  LOSSLESS 
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The  relations  are  SYNTHESIZED, 

FD-PRESERVING,  LOSSLESS,  and  MINIMAL  relations 


Now,  ASSIGN  the  relation  name  for  new  relation(s). 

New  Decomposed  Relations: 

(MISSION_NUMBER,  A/C_CALLSIGN,  REQUEST_NUMBER) 

Enter  A  new  name  for  the  relation  above  => 

New  Decomposed  Relations: 

(MISSION.NUMBER,  A/C_CALLSIGN  ;  ALERT_STATUS, 

PRIMARY_CONnGURATION_CODE,  SECONDARY_CONFIGURATION_CODE, 

IFF/SIF_CODES,  EST.TTME. AIRBORNE,  EST_’nME_OF_RETURN) 

Enter  A  new  name  for  the  relation  above  ==> 

New  Decomposed  Relations: 

(A/C_CALLSIGN  :  NUMBER_OF_AIRCRAFT,  AIRCRAFT_TYPE) 

Enter  A  new  name  for  the  relation  above  => 

New  Decomposed  Relations: 

(MISSION_NUMBER  :  MISSION_TYPE) 

Enter  A  new  name  for  the  relation  above  => 


FDs  after  Normalization 

1.  MISSION.NUMBER  A/C_CALLSIGN  — ->  ALERT_STATUS 
PRIMARY_CONnGURAnON_CODE  SECONDARY.CONHGURATION.CODE 
IFF/SIF_CODES  EST.TTME. AIRBORNE  EST_TIME_OF_RETURN 

2.  A/C_CALLSIGN  — >  NUMBER_OF_AIRCRAFT  AIRCRAFT.TYPE 

3.  MISSION.NUMBER  — >  MISSION_TYPE 


ENTERING  FD  FOR  THE  RELATION:  TARGET_LOCATION 

TARGET_LOCATION  (TARGET_IDENTIFIER,  MISSION.NUMBER,  A/C_CALLSIGN, 
REQUEST_NUMBER,  TIME-ON-TARGET,  TIME-OFF-TARGET,  TARGET_TYPE, 
LOCATION,  TARGET_COMMENTS) 


Candidate  keys= 

1  TARGETJDENTIFIER  MISSION.NUMBER  A/C_CALLSIGN  REQUEST_NUMBER 


All  Fd’s  entered  for  this  relation 

1:  TARGETJDENTEFIER  — >  TIME-ON-TARGET  TIME-OFF-TARGET  TARGET_TYPE 
LOCATION  TARGET.COMMENTS 
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RESULT  OF  CHECKING  NORMAL  FORMS  FOR  RELATION  (TARGET_LOCATION) 


NOTATION:  Y  :  SATISFACTORY  N  :  NOT  SATISFACTORY 

FD  no.  BCNF  3NF 

1  N  N 

Removing  the  EXTRANEOUS  ATTRIBUTES  begins . 

No  extraneous  attribute  found 

SEARCHING  for  REDUNDANT  FDs  begins . 

NO  redundant  FD  found. 

CONSTRUCnON  OF  RELATIONS  begins . 

The  relation  (TARGET_LOCATION)  was  SYNTHESIZED  and  MINIMIZED  as  follows: 
Original  Relation  is  decomposed  to  : 

(TARGET_IDENTinER,  MISSION.NUMBER,  A/C_CALLSIGN,  REQUEST_NUMBER) 
(TARGET_IDENTinER  :  TIME-ON-TARGET,  TIME-OFF-TARGET,  TARGET_TYPE, 
LOCATION,  TARGET_COMMENTS) 

Checking  for  LOSSLESS  JOIN  begins.... 

Decomposition  is  LOSSLESS 
The  relations  are  SYNTHESIZED, 

FD-PRESERVING,  LOSSLESS,  and  MINIMAL  relations 

Now,  ASSIGN  the  relation  name  for  new  relation(s). 

New  Decomposed  Relations: 

(TARGET_IDENTinER,  MISSION_NUMBER,  A/C_CALLSIGN,  REQUEST_NUMBER) 
Enter  A  new  name  for  the  relation  above  => 

New  Decomposed  Relations: 

(TARGET.IDENTmER  :  TIME-ON-TARGET,  TIME-OFF-TARGET,  TARGET_TYPE, 
LOCATION,  TARGET_COMMENTS) 

Enter  A  new  name  for  the  relation  above  => 

FDs  after  Normalization 

1.  TARGETJDENTIFIER  — >  TIME-ON-TARGET  TIME-OFF-TARGET  TARGET_TYPE 
LOCATION  TARGET.COMMENTS 


ENTERING  FD  FOR  THE  RELATION:  IMMEDIATE_REQUESTS 
IMMEDIATE.REQUESTS  (IMMEDIATE_AIR_REQUEST_NUMBER,  UNIT_SUPPORTED) 
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Candidate  keys= 

I  IMMEDIATE. AIR_REQUEST_NUMBER 


All  Ed’s  entered  for  this  relation 

1:  IMMEDIATE_AIR_REQUEST_NUMBER  — >  UNTT.SUPPORTED 


RESULT  OF  CHECKING  NORMAL  FORMS  FOR  RELATION 
(IMMEDIATE.REQUESTS  ) 

NOTATION;  Y  :  SATISFACTORY  N  :  NOT  SATISFACTORY 
FD  no.  BCNF  3NF 

1  Y  Y 


Removing  the  EXTRANEOUS  ATTRIBUTES  begins . 

No  extraneous  attribute  found 

SEARCHING  for  REDUNDANT  FDs  begins . 

NO  redundant  FD  found. 

FDs  after  Normalization 

1.  IMMEDIATE_AIR_REQUEST_NUMBER  — >  UNTT.SUPPORTED 


ENTERING  FD  FOR  THE  RELATION:  RECONNAISSANCE 

RECONNAISSANCE  (REQUEST.NUMBER,  PRIORITY,  MISSION.START, 
MISSION.STOP,  LATEST_TIME_INFO_OF_VALUE,  MISSION.TYPE, 
COVERAGE.TYPE) 


Candidate  keys= 

1  REQUEST.NUMBER 

All  Fd’s  entered  for  this  relation 

1:  REQUEST.NUMBER  — >  PRIORITY  MISSION.START  MISSION.STOP 
LATEST_TIME_INFO_OF_VALUE  MISSION.TYPE  COVERAGE.TYPE 


RESULT  OF  CHECKING  NORMAL  FORMS  FOR  RELATION  (  RECONNAISSANCE  ) 

NOTATION:  Y  .  SATISFACTORY  N  :  NOT  SATISFACTORY 

FD  no.  BCNF  3NF 
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1 


Y  Y 


Removing  the  EXTRANEOUS  ATTRIBUTES  begins . 

No  extraneous  attribute  found 

SEARCHING  for  REDUNDANT  FDs  begins . 

NO  redundant  FD  found. 

FDs  after  Normalization 

1.  REQUEST_NUMBER  — >  PRIORITY  MISSION_START  MISSION_STOP 
LATEST_TIME_INFO_OF_VALUE  MISSION_TYPE  COVERAGE_TYPE 


ENTERING  FD  FOR  THE  RELATION;  RECON_TARGET 

RECON_TARGET  (LOCATION,  TARGET_LENGTH,  TARGET.WIDTH) 

Candidate  keys= 

1  LOCATION 

All  Fd’s  entered  for  this  relation 
1:  LOCATION  — >  TARGET.LENGTH  TARGET.WIDTH 


RESULT  OF  CHECKING  NORMAL  FORMS  FOR  RELATION  (RECON.TARGET) 
NOTATION:  Y  :  SATISFACTORY  N  :  NOT  SATISFACTORY 

FD  no.  BCNF  3NF 

1  Y  Y 

Removing  the  EXTRANEOUS  ATTRIBUTES  begins . 

No  extraneous  attribute  found 

SEARCHING  for  REDUNDANT  FDs  begins . 

NO  redundant  FD  found. 

FDs  after  Normalization 

1.  LOCATION  — >  TARGET_LENGTH  TARGET.WIDTH 


ENTERING  FD  FOR  THE  RELATION:  COMPRISES 
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COMPRISES  (ATO_START.  ATO_STOP.  AIR_TASKING_CODE,  MISSION_NUMBER, 
A/C_CALLSIGN) 


ENTERING  FD  FOR  THE  RELATION:  ASSESSES 

ASSESSES  (TARGETJDENTinER,  LOCATION,  TIME-ON-TARGET, 
TIME-OFF-TARGET) 

Candidate  keys= 

1  TARGETJDENTIFIER  TIME-ON-TARGET  TIME-OFF-TARGET 

All  Fd’s  entered  for  this  relation 
1:  TARGETJDENTinER  — >  LOCATION 


RESULT  OF  CHECKING  NORMAL  FORMS  FOR  RELATION  (  ASSESSES  ) 
NOTATION:  Y  :  SATISFACTORY  N  :  NOT  SATISFACTORY 

FD  no.  BCNF  3NF 

1  N  N 

Removing  the  EXTRANEOUS  ATTRIBUTES  begins . 

No  extraneous  attribute  found 

SEARCHING  for  REDUNDANT  FDs  begins . 

NO  redundant  FD  found. 

CONSTRUCnON  OF  RELATIONS  begins . 

The  relation  (ASSESSES)  was  SYNTHESIZED  and  MINIMIZED  as  follows: 
Original  Relation  is  decomposed  to  ; 

(TARGET JDENTIFIER,  TIME-ON-TARGET,  TIME-OFF-TARGET) 
(TARGET_IDENTIFIER  :  LOCATION) 

Checking  for  LOSSLESS  JOIN  begins.... 

Decomposition  is  LOSSLESS 
The  relations  are  SYNTHESIZED, 

FD-PRESERVING,  LOSSLESS,  and  MINIMAL  relations 

Now,  ASSIGN  the  relation  name  for  new  rclation(s). 

New  Decomposed  Relations: 

(TARGETJDENTinER,  TIME-ON-TARGET,  TIME-OFF-TARGET) 

Enter  A  new  name  for  the  relation  above  => 
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New  Decomposed  Relations; 
(TARGETJDENTinER  :  LOCATION) 

Enter  A  new  name  for  the  relation  above  ==> 


FDs  after  Normalization 
1.  TARGETJDENTIFIER  —>  LOCATION 


ENTERING  FD  FOR  THE  RELATION:  CONTROLS 
CONTROLS  (MISSION_NUMBER,  A/C_CALLSIGN,  CALLSIGN) 

ENTERING  FD  FOR  THE  RELATION;  REQUESTS 

REQUESTS  (IMMEDIATE_AIR_REQUEST_NUMBER,  MISSION_NUMBER, 
A/C_CALLSIGN) 


ENTERING  FD  FOR  THE  RELATION:  INTEREST  IN 

INTERESTJN  (LOCATION,  REQUEST_NUMBER) 

Candidate  keys= 

1  REQUEST.NUMBER 

All  Fd’s  entered  for  this  relation 
1:  REQUEST_NUMBER  — >  LOCATION 


RESULT  OF  CHECKING  NORMAL  FORMS  FOR  RELATION  ( INTEREST_IN  ) 
NOTATION:  Y  :  SATISFACTORY  N  :  NOT  SATISFACTORY 

FD  no.  BCNF  3NF 

I  Y  Y 

Removing  the  EXTRANEOUS  ATTRIBUTES  begins . 

No  extraneous  attribute  found 


SEARCHING  for  REDUNDANT  FDs  begins 
NO  redundant  FD  found. 
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FDs  after  Normalization 
1.  REQUEST_NUMBER  — >  LOCATION 

ENTERING  FD  FOR  THE  RELATION:  MAY_DESIGNATE 
MAY.DESIGNATE  (A/C_C ALLSIGN,  MISSION_NUMBER,  POINT_NUMBER) 


ENTERING  FD  FOR  THE  RELATION;  UPDATES 

UPDATES  (ATO_START,  ATO_STOP,  AIR_TASKING_CODE,  MISSION_NUMBER) 


ENTERING  FD  FOR  THE  RELATION;  REFUELS 

REFUELS  (MISSlON_NUMBER,  A/C_CALLSIGN,  REQUEST_NUMBER) 

Candidate  keys= 

1  A/C_CALLSIGN  REQUEST_NUMBER 
All  Fd’s  entered  for  this  relation 

1:  A/C_CALLSIGN  REQUEST_NUMBER  — >  MISSION.NUMBER 


RESULT  OF  CHECKING  NORMAL  FORMS  FOR  RELATION  (  REFUELS  ) 
NOTATION:  Y  :  SATISFACTORY  N  :  NOT  SATISFACTORY 

FD  no.  BCNF  3NF 

1  Y  Y 

Removing  the  EXTRANEOUS  ATTRIBUTES  begins . 

No  extraneous  attribute  found 

SEARCHING  for  REDUNDANT  FDs  begins . 

NO  redundant  FD  found. 

FDs  after  Normalization 

1.  A/C_CALLSIGN  REQUEST.NUMBER  — >  MISSION_NUMBER 
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Normalizer  Functional  Dependencies  Summary 


ASSESSES  FDs 

TARGETJDENTinER 
— > 

LOCATION 


CONTROLS  FDs 

CALLSIGN 
— > 

CONTROL_AGENCY 

PRIMARY_FREQUENCY 

SECONDARY_FREQUENCY 

CONTROL_AGENCY 
— > 

CONTROL_POINT 
IMMEDIATE  FDs 

IMMEDIATE_AIR_REQUEST_NUMBER 
— > 

UNTT.SUPPORTED 


INTEREST  FDs 

REQUEST_NUMBER 
— > 

LOCATION 


MISSION  FDs 

REQUEST_NUMBER 
— > 

LOCATION_TYPE 

LOCATION 
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MISSION_NUMBER 
A/C_CALLSIGN 
REQUEST_NUMBER 
— > 

ALTITUDE 

MISSION_COMMENT 


MSN  FDs 

MISSION_NUMBER 
A/C_CALLSIGN 
— > 

ALERT_STATUS 

PRIMARY_CONnGLTRATION_CODE 
SECOND  ARY_CONnGURATION_CODE 
IFF/SIF_CODES 

A/C_CALLSIGN 
— > 

NUMBER_OF_AIRCRAFT 

AIRCRAFT_TYPE 

MISS10N_NUMBER 
— > 

MISSION_TYPE 


RECEIVING  FDs 

MISSION_NUMBER 
A/C_CALLSIGN 
— > 

NUMBER_OF_AIRCRAFT 

A1RCRAFT_TYPE 

AMOUNT_OF_FUEL 

REFUELING_TIME 

NUMBER_OF_AIRCRAFT 
AMOUNT_OF_FUEL 
— > 

FUEL_REQUIREMENTS 
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RECON  FDs 


REQUEST_NUMBER 

— > 

PRIORm* 

MISSION_START 

MISSION_STOP 

LATEST_TIME_INFO_OF_VALUE 

MISSION_TYPE 

COVERAGE_TYPE 


RECONTGT  FDs 

LOCATION 
— > 

TARGET_LENGTH 

TARGET_WIDTH 


REFUELS  FDs 

A/C_CALLSIGN 
REQUEST_NUMBER 
— > 

MISSION_NUMBER 


TARGET  FDs 

TARGETJDENTIFIER 
— > 

TIME-ON-TARGET 

TIME-OFF-TARGET 

TARGET_TYPE 

LOCATION 

TARGET_COMMENTS 
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APPENDIX  G:  NORMALIZED  RELATIONAL  SCHEMA 


AIR_TASKING_ORDER  {ato  start,  ato  stop,  air  tasking  code  :) 

ROUTE  {mission  jiumber,  point_number  ;  control_point_type,  location,  arrival_tinie) 

RIO_LOGS  {mission  Jiumber  :  actual_time_of_amval,  actuaI_time_of_retum) 

BATTLE_DAMAGE_ASSESSMENT  {location,  time-on-target,  time-off-target  : 
percent_ordanance_on_target,  percent_target_destroyed,  bda_coniment,  unit_supported) 

IMMEDIATE_REQUESTS  {immediate jiirjequest jiumber  :  unit_supported) 

RECON_TARGET  {location  :  target_length,  targe t_width) 

COMPRISES  {atojtart,  ato_stop,  air  tasking  code,  mission  number,  ale  callsign  :) 
CONTROLS  {mission Jiumber,  dicjallsign,  callsign  :) 

REQUESTS  {immediate jiirjequest  Jiumber,  mission  jiumber ,  alcjallsign  :) 
INTEREST_IN  {request jiumber  :  location) 

MAY_DESIGNATE  {alcjallsign,  mission  jiumber,  point  jiumber  :) 

UPDATES  {atojtart,  atojtop,  airjaskingjode,  mission  jiumber  :) 

REFUELS  {alcjallsign,  request  jiumber  :  mission_number) 

COMMUNICATION_DATA  {callsign  :  control_agency,  primary_frequency, 
secondary_frequency) 

REPORT-IN_POINTS  {control  jgency  :  control_point) 

RECEIVING_AIRCRAFT  {mission jumber,  alcjallsign  :  number_of_aircraft,  aircraft_type, 
amount_of_fuel,  refueling_time) 

FUEL_REQUIREMENTS  {number jfjir craft,  amount jf fuel :  fuel_requiremcnts) 
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REQ_LOCATION  {request  number  :  location_type,  location) 

REQ_STATUS  {mission _number,  aic  callsign,  request jtumber  :  altitude,  mission_comment) 

MSN_STATUS  {mission jiumber,  aic  callsign,  request  number  ;) 

A/C_STATUS  {mission Jiumber,  alcjrallsign  :  aleTt_status,  primary_configuration_code, 
secondary_configuration_code,  iff/sif_codes,  est_time_airbome,  est_time_of_retum) 

A/C_WEAPONS  {alcjrallsign  :  nuniber_of_aircraft,  aircraft_type) 

MSN_TYPE  {mission  jumber  :  mission_type) 

TGT_MSN  {tar  get  identifier ,  mission  jumber,  alcjallsign,  request  jumber  -.) 

TGT_DATA  {target  jdentifier  ;  time-on-target,  time-off-target,  target_type.  location, 
target_comments ) 

TGT-TIME  {target  identifier .  time-on-target,  time-off-target :) 

TGT-ID_LOCN  {tar  get  jdentifier  :  location) 

RECON_REQUEST  {request jiumber  :  priority,  mission_stait,  mission_stop, 
latest_time_info_of_value,  mission_type,  coverage_type) 
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Normalized  Relational  Schema  File  Format 


AIR_TASKING_ORDER  3  3 

ATO_START  C,7 

ATO_STOP  C,7 

AIR_TASKING_CODE  C,43 

ROLTTE  5  2 

MISSION_NUMBER  C,8 

POINT_NUMBER  N,2 

CONTROL_POINT_TYPE  C,3 

LOCATION  C,20 

ARRIVAL_TIME  C,7 

RIO_LOGS  3  1 

MISSION.NUMBER  C,8 

ACTUAL_TIME_OF_ARRIVAL  N,4 

ACTUAL_TIME_OF_RETURN  N,4 

BATTLE_DAMAGE_ASSESSMENT  7  3 

LOCATION  C,20 

TIME-ON-TARGET  C,7 

TIME-OFF-TARGET  C,7 

PERCENT_ORDANANCE_ON_TARGET  N,2 
PERCENT_TARGET_DESTROYED  N,2 

BDA_COMMENT  C,30 

UNIT_SUPPORTED  C,9 

IMMEDIATE.REQUESTS  2  1 

IMMEDIATE_AIR_REQUEST_NUMBER  C,5 
UNIT_SUPPORTED  C,9 

RECON.TARGET  3  1 

LOCATION  C,20 

TARGET_LENGTH  C,7 

TARGET_WIDTH  C,7 

COMPRISES  5  5 

ATO.START  C,7 

ATO.STOP  C,7 

AIR_TASKING_CODE  C,43 

MISSION_NUMBER  C,8 

A/C_CALLSIGN  C,12 


% 
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CONTROLS  3  3 

MISSION_NUMBER  C,8 

A/C_CALLSIGN  C,12 

CALLSIGN  C,15 

REQUESTS  3  3 

IMMEDIATE_AIR_REQUEST_NUMBER  C,5 
MISSION_NUMBER  C,8 

A/C_CALLSIGN  C,12 

INTEREST_IN  2  1 

REQUEST_NUMBER  C,6 

LOCATION  C,20 

MAY_DESIGNATE  3  3 

A/C_CALLSIGN  C,I2 

MISSION_NUMBER  C,8 

POINT_NUMBER  N.2 

UPDATES  4  4 

ATO_START  C,7 

ATO_STOP  C,7 

AIR_TASKING_CODE  C,43 

MISSION_NUMBER  C,8 

REFUELS  3  2 

A/C_CALLSIGN  C,I2 

REQUEST_NUMBER  C,6 

MISSION.NUMBER  C,8 

COMMUNICATION_DATA  4  I 

CALLSIGN  C,15 

CONTROL_AGENCY  C,4 

PRIMARY_FREQUENCY  C,8 

SECONDARY_FREQUENCY  C,8 

REPORT-IN_POINTS  2  I 

CONTOOL_AGENCY  C,4 

CONTROL_POINT  C,20 
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RECEIVING_AIRCRAFT  6  2 

MISSION_NUMBER  C.8 

A/C_CALLSIGN  C.12 

NLIMBER_OF_AIRCRAFT  N,2 

AIRCRAFT_TYPE  C,6 

AMOUNT_OF_FUEL  N,4 

REFUELING_TIME  C.7 

FUEL_REQUIREMENTS  3  2 

NUMBER_OF_AIRCRAFT  N,2 

AMOUNT_OF_FUEL  N,4 

FUEL_REQUIREMENTS  N,4 

REQ_LOCATION  3  1 

REQUEST_NLnvrBER  C,6 

LOCATION_TYPE  C,6 

LOCATION  C,20 

REQ_STATUS  5  3 

MISSION_NUMBER  C,8 

A/C_CALLSIGN  C,12 

REQUEST_NUMBER  C,6 

ALTITUDE  C,5 

MISSION.COMMENT  C,22 

MSN_STATUS  3  3 

MISSION_NUMBER  C,8 

A/C_CALLSIGN  C,12 

REQUEST_NUMBER  C,6 

A/C_STATUS  8  2 

MISSION_NUMBER  C,8 

A/C_CALLSIGN  C,12 

ALERT_STATUS  C,3 

PRIMARY_CONnGURATION_CODE 
SECONDARY_CONnGURATION_CODE  C,5 
IFF/SIF_CODES  C,5 

EST_TIME_AIRBORNE  N,4 

EST_TIME_OF_RETURN  N,4 
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AyC_WEAPONS  3  1 

A/C_CALLSIGN  C,12 

NUMBER_OF_AIRCRAFT  N,2 

AIRCRAFT_TYPE  C,6 

MSN_TYPE  2  1 

MISSION_NUMBER  C,8 

MISSION_TYPE  C,5 

TGT_MSN  4  4 

TARGETJDENTIFIER  C,20 

MISSION_NUMBER  C,8 

A/C_CALLSIGN  C,12 

REQUEST_NUMBER  C,6 

TGT_DATA  6  1 

TARGETJDENTinER  C,20 

TIME-ON-TARGET  C,7 

TIME-OFF-TARGET  C,7 

TARGET_TYPE  C,6 

LOCATION  C,20 

TARGET_COMMENTS  C,35 

TGT-TEME  3  3 

TARGETJDENTinER  C,20 

TIME-ON-TARGET  C,7 

TTME-OFF-TARGET  C,7 

TGT-ID_LOCN  2  1 

TARGET JDENTIFIER  C,20 

LOCATION  C,20 

RECON_REQUEST  7  1 

REQUEST_NUMBER  C.6 

PRIORITY  C,1 

MISSION_START  C,7 

MISSION_STOP  C,7 

LATEST_TIME_INFO_OF_VALUE  C,ll 

MISSION.TYPE  C,5 

COVERAGE_TYPE  C,7 
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APPENDIX  H:  dBASE  IV  REPORTS 


Retrieving  information  in  dBASE  TV  is  accomplished  through  queries.  Queries  generate 
views  of  the  database  to  meet  the  user  and  application  requirements.  Views  are  virtual 
databases,  logical,  not  physical  stmetures.  Views  allow: 

•  data  to  be  seen  in  different  ways  without  physical  duplication 

•  manipulation  of  data  without  changing  original  database 

-  database  security 

-  users  to  be  shielded  from  changes  in  the  physical  database 

The  query  generated  views  are  used  by  user  for  "on  the  fly"  manipulation  of  data,  or  by  the 
application  for  report  and  form  generation.  Tables  are  linked  to  one  another  in  the  DASC 
database  through  queries,  and  views,  fomis,  and  reports  developed  using  these  multiple  tables. 
The  following  examples  show  the  capabilities  of  the  DASC  application: 

•  Report-In/Out  Log  view  that  links  multiple  tables 

•  BDA  update  form  for  data  insertion  of  BDA  data 

•  Immediate  Air  Support  Report  that  lists  immediate  air  support  requests  received, 
supported  unit,  mission  assignment  and  BDA 

•  Report-In/Out  Log  Report 
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Organize  Fields  Go  To  Exit 
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IMMEDIATE  AIR  SUPPORT  SUMMARY  REPORT 
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